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HUMAN  PERFORMANCE  RELIABILITY 
IN  COMMAND  AND  CONTROL  SYSTEMS: 

THE  NAVAL  TACTICAL  DATA  SYSTEM  (U) 

INTRODUCTION 

(U)  The  study  of  human  performance  reliability  in  any  real- 
life  situation  must  meet  at  least  one  basic  requirement: 
the  existence  of  operational  performance  data.  If  perfor¬ 
mance  data  are  not  taken  from  operational  situations,  it  may 
matter  little  that  one  has  a  scheme  to  "model"  performance 
reliability.  The  techniques  and  tools  are  available  to 
construct  human  reliability  models;  how  useful  a  given  model 
will  be  in  predicting  human  performance  in  a  given  situation 
will  depend  largely  on  the  availability  of  relevant  data  to 
implement  the  model.  Swain  (1969),  in  an  overview  of  the 
status  of  human  factors  reliability  analysis,  concluded  the 
primary  need  is  for  a  "central  bank"  of  human  performance 
data. 

Several  years  ago,  we  had  reached  the  point 
where  our  mathematics  and  reliability  tech¬ 
nology  had  far  outstripped  the  available 
human  performance  data.  Today,  if  anything, 
the  gap  has  widened. 

(U)  There  had  been  an  attempt  to  establish  a  central  data 
bank  of  human  performance  reliability  (the  AIR  data  store, 
e.g.,  Altman,  1964).  But  the  performance  data  in  the  bank 
was  derived  mainly  from  laboratory  studies,  not  from  opera¬ 
tional  performance  situations.  The  level  of  task  descrip¬ 
tion  was  in  terms  of  task  elements ,  such  as  the  time  required 
to  engage  a  toggle  switch  and  the  probability  of  a  correct 
response,  or  the  time  and  probability  of  correctly  reading  a 
numeral  of  given  dimensions.  The  data  in  the  bank,  then, 
were  times  and  probabilities  associated  with  very  small  units 
of  performance.  The  performance  of  any  reasonably , complex 
operational  task  would  comprise  a  great  many  such  units.  A 
major  problem  concerns  how  to  combine  these  units  to  come  up 
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with  some  measure  of  task  reliability,  rather  than  of  task 
element  reliabilities* 

(U)  The  main  requirements  for  a  useful  human  performance 
data  bank  are  that  the  data  be  collected  under  operational 
conditions,  that  the  conditions  be  clearly  specified,  that 
the  level  of  task  description  be  " appropr i ate , n  and  that 
the  user  of  the  bank  be  taken  into  account*  "Operational 
conditions"  covers  a  wide  range  of  variables  that  affect 
human  performance,  from  the  characteristics  of  performers 
to  the  performance  environment.  A  practical  operational 
performance  data  bank  cannot  reflect  all  the  conditions  of 
performance,  but  the  significant  conditions  must  be  repre¬ 
sented,  An  "appropriate"  level  of  task  description  is 
likely  a  level  of  organization  considerably  higher  than  task 
elements.  The  probable  user  of  an  operational  data  bank  is 
the  system  designer.  If  the  bank  is  to  be  useful  to  him, 
the  data  must  be  in  terms  that  he  can  understand  and  apply 
at  the  various  stages  of  system  evaluation.  The  "search" 
terms  of  the  bank,  probably  terms  that  refer  to  system  func¬ 
tions,  at  the  highest  level  of  term  organization,  should 
enable  him  to  retrieve  relevant  data  quickly. 

Study  Objectives 

( U)  The  main  purpose  of  this  study  was  to  determine  the 
requirements  for  the  development  of  an  operational  data  bank 
of  human  performance  in  command- and- cont ro 1  systems.  To 
achieve  this  purpose  it  was  necessary  to  conduct  a  detailed 
analysis  of  a  specific  comman d- and- con t r o 1  system. 

(C)  The  system  selected  for  analysis  was  the  Naval  Tactical 
Data  System  (NTDS) .  This  is  a  highly  automated,  computerized 
system  in  wide  use  in  the  Navy.  It  is  likely  that  future 
systems  will  follow  the  NTDS  model,  rather  than  earlier,  less 
automated  system  models.  The  NTDS  surely  contains  all  the  ele¬ 
ments  of  command- and- con tro 1  systems:  allocating  and  keeping 
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track  of  forces,  detecting  and  keeping  track  of  targets , 
identifying  targets,  deciding  what  to  do  about  them,  select- 
ing  appropriate  actions,  and  taking  the  actions.  In  short, 
the  NTDS  is  a  highly  sophisticated  information  processing 
sysTenTT  ~~ 

(U)  Staff  members  of  the  Human  Factors  Division  of  the  Naval 
Electronics  Laboratory  Center  (NELC)  participated  in  this 
study.  Their  major  contributions  were  in  the  development  of 
an  automatic  recording  system  (called  the  Data  Recording 
System)  and  in  cooperation  in  the  design  and  execution  of 
the  study. 

(U)  The  specific  objectives  of  the  study  were  as  follows: 

1.  Develop  a  functional  system  description,  partic¬ 
ularly  of  man-man  and  man-machine  interactions. 

2.  Develop  detailed  task  descriptions  of  selected 
tasks . 

3.  Evaluate  operational  data  collection  methods. 

a.  Direct  recording  of  system  events. 

b.  Observations  of  system  events. 

c.  Judgments  of  operator  performance. 

4.  Identify  system  performance  criteria. 

5.  Identify  the  variables  that  affect  system 
performance . 

6.  Develop  a  taxonomy  of  task  performance  and 
an  error  classification  scheme. 

7.  Determine  the  characteristics  of  an  opera¬ 
tional  data  bank. 

8.  Develop  a  plan  for  continued  research. 

Study  Activities 

(U )  The  main  activities  of  the  study  are  described  briefly 
in  the  following  paragraphs.  The  outcomes  of  these  activities 
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are  described  in  following  sections  of  the  report. 

Information  Sources 

(U)  A JTDS  Documentation.  The  NTDS  Input  and  User  Operator 
Manuals  were  reviewed  and  analyzed  in  detail.  These  manuals 
contain  brief  general  descriptions  of  each  NTDS  operator 
task.  In  addition,  they  provided  a  functional  description 
of  the  NTDS  consoles  in  each  mode  of  operation.  See  the 
references  for  a  list  of  other  NTDS  documents  reviewed 
during  the  study. 

(C)  Observations.  Project  personnel  spent  more  than  seven 
man-weeks  visiting  FAAWTC  San  Diego  and  NTDS- equipped  ships 
in  the  Southern  California  area  during  the  course  of  the 
study.  A  part  of  nearly  every  day  was  spent  observing  NTDS 
operations,  witnessing  demonstrations,  or  operating  NTDS 
equipment.  Project  personnel  visited  the  USS  GRIDLEY  (DLG  21), 
USS  JOUETT  (DLG  29),  USS  HORNE  (DLG  30),  and  the  USS  FOX 
(DLG  33).  In  addition,  one  member  of  the  project  staff  spent 
a  week  on  board  the  USS  STERET  (DLG  31).  This  latter  experi¬ 
ence  was  particularly  useful  in  illustrating  the  difference 
between  classroom  or  textbook  NTDS  and  the  reality  of  ship¬ 
board  NTDS  operations. 

(C)  Interviews .  Numerous  interviews  were  conducted  with 
NTDS  instructors  and  operational  personnel.  In  fact,  many 
more  interviews  were  conducted  than  had  been  anticipated  due 
largely  to  the  inadequacy  of  the  NTDS  operator  manuals.  The 
purpose  of  these  interviews  was  to  supplement  the  information 
in  the  Operator  Manuals,  identify  training  and  operational 
problems,  and  to  establish  working  relationships  with  key  NTDS 
personnel  at  FAAIVTC,  COMCRUDES P AC ,  and  NELC. 

(u)  At  FAAWTC,  San  Diego,-  instructors  specialize  in  teaching 
one  or  more  of  various  modes  of  NTDS  console  operation.  Usu¬ 
ally  two  or  more  instructors  are  assigned  to  teacli  each  console 
Interviews  were  conducted  with  one  or  more  instructors 
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assigned  to  each  console  mode.  A  part  of  every  such  interview 
was  a  discussion  of  the  problems  each  operator  has  in  inter¬ 
facing  with  the  system  and  with  the  other  console  operators. 

(U)  Similarly,  interviews  were  conducted  with  each  type  of 
operator  aboard  ship. 

(C)  One  of  the  more  interesting  aspects  of  each  of  these 
interviews  was  a  discussion  of  performance  standards.  No 
one  was  aware  that  there  were  any  standards,  but  everyone 
had  an  opinion  of  what  standards  should  be,  and  there  was  a 
great  deal  of  variability  in  the  opinions  expressed. 

(C)  HFR  Projects.  Of  the  ongoing  HFR  projects  that  relate 
to  this  study,  one  is  of  particular  interest.  This  project, 
sponsored  by  ARPA,  is  concerned  with  developing  procedures 
for  allocating  functions  between  men  and  machines  in  future 
generations  of  automated  surveillance  systems.  Considerable 
effort  has  been  expended  during  this  study  to  develop  system 
and  operator  task  descriptions,  develop  a  task  taxonomy,  and 
identify  performance  parameters  and  criteria. 

(U)  The  similarities  and  differences  between  the  ARPA  study 
and  this  one  have  perhaps  provided  a  clearer  insight  into 
both  projects. 

(U)  General  Literature .  The  general  literature  on  human 
performance  reliability  and  the  development  of  task  taxonomies 
was  reviewed.  A  particularly  useful  reference  has  been 
Miller's  (1971)  study  of  a  taxonomy  of  human  performance. 

Analytical 

(C)  Functional  System  Description.  The  development  of  a 
functional  description  of  the  NTDS  was  fairly  straightforward. 
At  the  level  of  overall  system  objectives  it  is  fairly  simple 
to  infer  these  objectives  from  the  material  presented  in  the 
system  manuals.  It  would  seem,  however,  that  a  publication 
that  described  the  system  objectives  and  which  discussed  in 
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some  detail  the  differences  between  NTDS  systems  would  be 
useful  not  only  to  researchers  but  to  operational  commanders 
and  training  commands  as  well. 

(C)  Functional  Task  Descriptions .  Many  difficulties  were 
encountered  in  developing  task  descriptions.  The  operator’s 
tasks  are  simply  not  described  very  well  in  the  operator 
manuals.  At  no  place  in  the  operator  manuals  are  procedures 
described.  Consequently,  it  was  necessary  to  spend  consid¬ 
erable  time  in  discussions  with  NTDS  personnel  to  arrive  at 
an  adequate  description  of  any  operator’s  task. 

(U)  Identification  of  Relevant  Variables .  Both  performance 
and  situational  variables  were  identified.  The  assistance 
of  fleet  and  training  personnel  was  sought  in  the  identifica¬ 
tion  of  variables.  An  attempt  was  made  to  obtain  an  estimate 
of  the  perceived  importance  to  operator  performance  of  the 
variables  identified,  and  to  identify  those  variables  ap¬ 
plicable  to  all  operators,  and  those  associated  with  only 
parti cular  operators. 

(C)  FAAWTC  San  Diego  Curriculum  and  Performance  Tests .  The 
entire  NTDS  curriculum  used  at  FAAWTC  San  Diego  was  reviewed 
and  analyzed.  The  performance  tests  used  were  also  analyzed. 
The  curriculum  objectives  and  performance  tests  do  not  in¬ 
clude  sys  tern- re  1  at  e  d  performance  criteria.  Initially  this 
was  thought  to  be  a  deficiency  in  the  curriculum  and  per¬ 
formance  tests.  Later  it  was  learned  that  the  deficiency, 
though  a  real  one  and  recognized  as  such  by  NTDS  instructors, 
does  not  reflect  the  competence  of  instruction  but  rather 
reflects  the  non-existence  of  NTDS  performance  standards. 

Developmental 

(C)  Judgmental  Data  Collection  Method .  The  first  task  in  the 
development  of  a  judgmental  data  collection  method  was  to  iden¬ 
tify  the  most  frequent / import  ant  errors  made  by  NTDS  operators. 
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The  original  intention  was  to  develop  an  exhaustive  list  of 
errors  for  each  operator.  With  such  lists  in  hand,  it  would 
have  been  possible  to  not  only  identify  the  relative  importance 
of  these  errors  for  individual  operators  but  to  also  analyze 
errors  across  operators.  This  plan  was  quickly  abandoned  when 
it  was  learned  that  identifying  operator  errors  would  be  far 
more  difficult  than  had  been  anticipated.  The  initial  error 
identification  effort  had,  however,  served  to  focus  our  atten¬ 
tion  on  the  Track  Supervisor  (TRK/SUP)  task  as  perhaps  the 
most  difficult  NTDS  task. 

(C)  The  TRK  SUP  is  the  Mman-in-the  middle1'  in  NTDS  operations. 
He  interfaces  with  every  other  member  of  own-ship's  NTDS  team 
and  his  performance  affects  the  performance  of  every  other 
operator.  Consequently,  the  details  of  the  TRK  SUP  task  are 
relatively  well  known  to  all  NTDS  operators.  Therefore,  it 
seemed  reasonable  to  expect  any  NTDS  operator  to  be  able  to 
judge  the  importance  and  frequency  of  TRK  SUP  errors. 

(C)  Some  50  errors  were  identified,  from  sources  available 
at  the  time,  that  the  TRK  SUP  might  make  in  performing  his 
several  tasks.  Through  interviews  and  pilot  tests  among 
FAAWTC  instructor  and  shipboard  personnel,  the  list  of  errors 
was  reduced  to  20  that  were  judged  to  be  important  and  to 
occur  relatively  frequently.  Judgments  were  obtained  from 
operational  personnel  on  two  NTDS  ships,  using  a  ranking 
method,  about  the  relative  importance  and  frequency  of  occur¬ 
rence  of  the  20  errors  under  different  tactical  conditions. 

(U)  Data  Reduction  Logic .  NELC  has  developed  the  Data  Re¬ 
cording  System  (DRS).  Briefly,  the  system  is  capable  of 
recording,  in  real  time,  events  in  the  NTDS  that  result  in  an 
electronic  signal,  such  as  button  pushing  responses,  track 
number  designators,  and  x-y  positions  of  tracks.  Thus,  the 
output  of  the  DRS  is  a  record  of  the  identification  of  an 
event  and  the  time  of  its  occurrence.  The  record  will  be 


•••  ••••  •••  ••••  ••• 


•  •  • 


•  •  • 


•  • 


j 


. . 

••  ••  ••  •  •••  •  •••••• 

•  •  •••  •  •••  •  ••  ••  •  •  •  •••••• 

••  •  •  •••  •  ••••  •  •  •  •  •  • 

•••  ••••  •••  •  •••  •••  •••  •  •  ••••  •••  •  •  •• 


computer  processed,  so  some  guidelines  were  needed  for  com¬ 
puter  programs . 

(C)  HFR  contributed  in  the  development  of  the  logic  required 
for  the  design  of  data  reduction  programs.  In  some  instances, 
the  interest  is  in  the  time  between  successive  events:  for 

example,  the  time  between  a  Firm  Track  entry  and  an  identifica¬ 
tion  response  entry  directly  gives  the  time  required  to  make 
an  identification  response.  The  reduced  data  required  are 
distribution  statistics,  perhaps  the  mean  and  variance  of 
response  times.  In  other  cases,  the  interest  is  in  the  se¬ 
quence  of  button  pushing  responses:  for  example,  a  Drop  Track 

response  immediately  following  a  gridlock  correction  sequence 
of  responses  may  indicate  an  invalid  track  has  been  in  the 
system.  The  reduced  data  required  is  the  frequency  of  occur¬ 
rence  of  such  events  and  performance  times  associated  with 
them.  The  data  reduction  logic  required  to  interpret  DRS 
recordings  is  often  complex  and  involves  a  consideration  of 
the  significance  of  given  events  in  relation  to  others. 

(U)  Observers  will  be  required  to  collect  operational  data 
that  cannot  be  directly  recorded,  such  as  operator  overt 
behavior  in  performing  given  tasks,  the  characteristics  of 
operators,  communications  between  operators,  and  the  presence 
of  variables  that  may  affect  performance.  There  is  a  require¬ 
ment  for  reduced  data;  for  example,  the  scaling  of  operator 
behavior  measures . 

(U)  Some  events  cannot  be  directly  recorded  or  observed, 
particularly  the  decision-making  processes  in  an  operator 
that  occur  between  overt  responses.  The  reduced  data  re¬ 
quirement  may  be  for  the  scaling  of  decision  task  difficulty 
measures . 

(U )  Task  Taxonomy  Development .  A  preliminary  task  taxonomy 
has  been  developed  that  seems  to  be  applicable  to  the  NTDS 
and  to  command- and- control  systems  in  general.  Error  classi¬ 
fication  schemes  also  have  been  considered. 
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(u)  Characteristics  of  an  Operational  Data  Bank.  The  total 
activity  of  this  study  has  been  directed  toward  developing 
the  characteristics  of  an  operational  data  bank.  The  data 
collection  methods,  the  form  of  reduced  data,  the  identifi¬ 
cation  of  relevant  variables,  the  level  of  task  descriptions, 
all  bear  on  the  characteristics  of  the  bank.  Some  likely 
characteristics,  taking  the  user  into  account,  have  been 
identified . 
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(u)  The  description  of  the  Naval  Tactical  Data  System  (NTDS) 
given  below  is  by  no  means  a  complete  and  detailed  one.  It 
is  a  description  of  selected  e lements - -se le ct ed  to  provide 
the  reader  with  an  overall  view  of  the  system  and  some  under- 
standing  of  its  complexity. 

General  Description 

(C)  NTDS  is  a  computer-controlled  multi-purpose  command-and- 
control  system.  The  system  capabilities  include  aut ojnat e d 
tactical  data  collection j  processing,  displaying,  and  report  - 


ing--the  system  collects,  processes,  and  displays  real-time 


information  required  by  command  for  tactical  decision  making. 

NTDS  correlates  sensor  and  communications  information  to  per¬ 
form  such  functions  as  target  detection,  location,  tracking, 
course  and  speed  computation,  identification,  and  determination 
of  the  number  of  attacking  units. 

(C)  NTDS  information  is  displayed  automatically  on  a  number 
of  operator  consoles  in  the  Combat  Information  Center  (CJC). 
Command  personnel  monitor  the  tactical  situation  and  issue 
necessary  orders.  Automated  display  of  real-time  tactical 
data  is  intended  to  enable  command  personnel  to  grasp  the  tac¬ 
tical  situation  quickly  and  accurately  with  little  effort, 
thus  permitting  them  to  concentrate  on  effective  weapons  direc¬ 
tion  and  force  allocation. 

(C)  When  more  than  one  NTDS  ship  is  operating  with  a  task  group, 
the  computers  of  the  NTDS  Parti cipa ti  ng  Units  (PUs)  are  linked 
together  by  a  communications  circuit  known  as  Link  11.  PUs  ex¬ 
change  real-time  NTDS  track  data  and  symbology  via  Link  11  (raw 
radar  video  is  not  exchanged  among  PUs).  Non-NTDS  ships  in  the 
task  group  participate  by  making  voice  radio  reports  of  own-ship 
targets  and  by  receiving  situation  reports  via  a  one-way  teletype 
link  (Link  14). 

(C)  There  are  some  differences  between  NTDS  systems  depending 
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on  the  class  of  ship  on  which  they  are  installed.  For  ex¬ 
ample,  large  shins,  CVAs  and  cruisers  may  have  three  or  four 
general-purpose  computers,  whereas  smaller  ships,  DLGs,  have 
but  two  computers.  Generally  speaking,  the  additional  com¬ 
puter  on  the  large  ships  provides  the  necessary  computer 
facility  required  for  air  traffic  control  and  for  increased 
ECM  capability.  There  are  programming  differences  existing 
between  ships  serviced  by  Fleet  Computer  Programming  Center, 
Pacific,  and  those  serviced  by  Fleet  Computer  Programming 
Center,  Atlantic.  These  programming  differences  relate  more 
directly  to  the  management  of  computer  capacity  than  they  do 
to  the  actual  operation  of  the  system. 

(C)  Another  difference  among  ship  types  is  in  the  number  of 
NTDS  consoles  installed.  Larger  ships  have  as  many  as  30 
consoles,  whereas  smaller  ships  have  as  few  as  10  consoles. 
On  large  ships,  particularly  CVAs,  the  "extra”  consoles  are 
used  in  non-combat  operations,  primarily  for  air  traffic 
management  and  control. 


(C)  On  each  ship,  the  consoles  are  divided  between  User  and 
Input  functions.  The  User  consoles  are  operated  by  personnel 
with  tactical  decision-making  responsibility.  The  Input 
consoles  are  operated  by  lower  echelon  personnel  who  are  not 
directly  involved  in  tactical  decision  making. 

(C)  Table  1  identifies  the  NTDS  User  and  Input  consoles  and 
operator  functions;  those  functions  indicated  by  asterisks 
were  analyzed  in  detail  for  the  purposes  of  this  study. 

TABLE  1 

/  NTDS  CONSOLES  AND  OPERATOR  FUNCTIONS 


Users  Input  Operators 


Flag 

1  . 

Air  Detector/Tracker 

Force  Weapons  Coordinator* 

2. 

Height  Size 

Ship's  'Weapons  Coordinator* 

3. 

Identification* 

]  2 
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TABLE  1 

NTDS  CONSOLES  AND  OPERATOR  FUNCTIONS 
(Continued ) 


Users 

4.  Intercept  Controller* •• ••• 

5.  Air  Traffic  Controller 

6.  Command  Mode 


Input  Operators 


4. 

SIF 

Tracker 

5 . 

Track  Supervisor* 

6 . 

ECM 

Su  perv i sor 

7  . 

Surface  Tracker 

8. 

Ai  r 

Operations  Tracker 

I 


Console  Description 

(C)  Each  console  is  a  multi-mode  console;  that  is,  any  of 
several  modes  of  operation  can  be  selected  at  a  particular 
console  by  selector  switch  action.  Although  NTDS  consoles 
can  be  operated  in  different  modes  it  is  customary  aboard 
ship  for  particular  consoles  to  be  used  in  only  one  mode, 
unless  equipment  casualties  or  other  unforeseen  events  occur. 
Moreover,  the  consoles  are  grouped  together  by  function-- the 
Input  consoles  are  located  in  one  area,  and  the  User  consoles 
in  another  area  usually  several  feet  away. 

(C)  There  have  been  four  generations  of  NTDS  consoles:  SYA-1, 
SYA-4,  UYA- 1 ,  and  UYA-4.  The  UYA-4  consoles  are  universal 
consoles,  that  is,  any  User  or  Input  mode  can  be  selected  on 
any  console.  In  the  previous  models  there  were  two  types  of 
consoles,  one  for  Users  and  another  for  Input  Operators. 

(C)  All  four  generations  of  NTDS  consoles  are  presently  in 
use  in  the  fleet.  In  their  appearance  and  functional  char¬ 
acteristics  the  various  models  are  quite  similar.  However, 
there  are  numerous  detailed  differences  between  consoles 
particularly  between  the  UYA-4  and  the  first  three  models. 

These  differences  are  sufficient  to  warrant  a  period  of  re¬ 
training  or  reindoctrination  if  a  man  is  transferred  from  a 
ship  with  one  type  of  console  to  a  ship  with  a  different  type. 
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is  compatible  with  any  model  of  NTDS  console.  This  can  provide 
the  opportunity  to  compare  performance  on  different  consoles.) 

(C)  Figure  1  shows  the  configuration  of  the  'JYA-4  Universal 
Display  Console.  The  main  displays  and  controls  are  iden¬ 
tified  below. 

Visual  Displays 

(C)  The  PPI  and  Scope  Symbology .  The  principal  NTDS  display 
is  a  standard  12-inch  PPI.  In  addition  to  raw  radar  video, 

NTDS  symbology  is  displayed  on  the  PPI  (see  Appendix  C  for  a 
listing  of  NTDS  symbology).  The  symbology  is  of  three  types: 
track  symbols,  engagement  symbology,  and  special  points  and 
lines.  The  shape  of  the  track  symbols  indicate  whether  a 
track  is  an  air,  surface,  or  subsurface  contact  and  whether 
the  track  has  been  identified  as  friend,  hostile,  or  unknown. 
Engagement  symbology  is  used  to  indicate  the  engagement 
status  of  each  target  and  force  weapon.  A  Pairing  Lin**  is 
used  to  indicate  which  weapon  is  assigned  to  which  target. 
Special  points  and  lines  are  used  to  display  information  of 
tactical  interest  not  directly  associated  with  the  location 
and  movement  of  friendly  or  hostile  forces,  such  as  clutter 
points,  approach  corridors  and  missile  envelopes. 

(C)  Data  Readout  (DRO).  The  DRO  is  used  to  display  amplify¬ 
ing  data  concerning  the  track  in  close  control.  There  is  a 
standard  DRO  display  associated  with  each  console  mode.  The 
information  displayed  in  the  standard  format  is  that  required 
most  often  by  a  particular  operator.  For  example,  the  stan¬ 
dard  Ship's  Weapons  Coordinator  DRO  displays  engagement  status 
information  and  the  standard  Track  Supervisor  DRO  format  dis¬ 
plays  track  status  information.  Each  operator,  by  Function 
Code  entry,  can  call  up  a  variety  of  DRO  formats  that  provide 
additional  amplifying  information. 
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CATERORY  READOUT 


Figure  1.  Configuration  of  the  UYA-4  Console. 
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(C)  Identification  of  Controls.  Most  of  the  console  knobs, 
switches,  and  buttons  perform  fixed  functions  and  have  per¬ 
manent  labels.  The  function  of  Quick  Action  Buttons  (QAB) 
is  dependent  on  console  mode.  The  QAB  labels  change  when 
the  console  mode  of  operation  is  changed. 


(C)  Mode  Identification .  The  mode  of  operation  selected  at 
a  console  is  displayed  to  the  operator  by  a  back-lighted  in¬ 
dicator.  The  lettering  displayed  on  the  indicator  changes 
with  each  change  of  mode. 


(C)  Function  Code  Identification .  Function  Codes  are  entered 
using  number  entry  dials  or  buttons.  The  numbers  entered  are 
displayed  to  the  operator  so  that  lie  can  verify  whether  they 
are  the  ones  he  intended  to  enter.  A  list  of  General  Purpose 
Function  Codes  is  usually  taped  to  the  bullnose  of  each  console. 

(C)  Alert  Panel.  The  Alert  Panel  consists  of  a  row  of  six 
lights.  Alerts  are  used  to  inform  the  operator  of  special 
situations  that  usually  require  his  immediate  attention.  When¬ 
ever  an  operator  performs  an  action  which  the  computer  will 
not  accept,  he  receives  an  Illegal  Action  alert.  The  alerts 
indicated  by  the  other  five  lights  or.  the  Alert  Panel  vary  as 
a  function  of  console  mode. 


Auditory  Displays 

(C)  Radio  Telephone .  The  Force  Weapons  Coordinator  (FWC), 
Ship  Weapons  Coordinator  (SWC) ,  Track  Supervisor  (TRK  SUP), 
Intercept  Controller  (1C),  and  the  Identification  Operator 
(ID)  communicate  with  other  units  via  voice  radio. 

(C)  Sound-Powered  Phene  (S/P).  All  members  of  the  NTDS 
C1C  team  are  linked  together  via  S/P  phones.  The  communica¬ 
tions  panel  located  on  the  NTDS  console  is  used  to  call  up 
particular  operators.  A  pointer  symbol  associated  with  this 
panel  enn  be  used  by  one  operator  to  indicate  position  on 
the  PPI  to  another  operator.  The  pointer  symbol  is  controlled 
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the  Track  Ball. 
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(C)  Buzaev  Signal.  Whenever  an  operator  receives  an  alert 
a  buzzer  sounds  to  draw  his  attention  to  the  alert.  The 
buzzer  is  silenced  when  the  operator  pushes  his  Alert  Review 
button. 


Contvo Is 

(C)  PPI  Display  Adjustment  Controls.  Each  NTDS  console  is 
equipped  with  controls  used  to  adjust  the  display  of  raw 
radar  video  on  the  PPI:  focus,  brightness,  astigmatism,  and 

so  on  . 


(C)  Category  Select  Panel.  The  Category  Select  Panel  is 
used  to  control  the  display  of  scope  symbology.  The  opera¬ 
tor  can  elect  to  have  all  symbols  displayed  or  deleted,  to 
have  certain  symbols  blink  under  specified  conditions,  or 
to  have  the  form  of  symbols  changed;  for  example,  all  remote 
or  friendly  tracks  may  be  displayed  as  dots  rather  than  as 
standard  symbols.  The  purpose  of  the  Category  Select  func¬ 
tion  is  to  reduce  scope  clutter  while  retaining  all  the  in¬ 
formation  needed  by  a  particular  operator  to  perform  his  task. 

(C)  Quick  Action  Buttons  (QABs).  QABs  are  used  by  the  opera¬ 
tor  for  rapid  communication  with  the  computer.  QABs  are  of 
two  types:  fixed  and  variable  function.  The  QABs  available 

at  each  console  vary  as  a  function  of  console  mode  selection. 
The  following  is  a  list  of  QABs  available  to  the  operators  of 
primary  interest  in  this  study. 

Force  Weapons  Coordinator  (FWC) 


1 . 

Alert 

Review 

2. 

Break 

Engage 

3. 

Cease 

Fire 

4  . 

Engage 

Interceptor 

S  . 

Engage 

M  i  s  s  i  1  e 
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6.  Position  Correction 

7.  Range  ancl  Bearing 

8.  Track  Review 

Ship  Weapons  Coordinator  ( SWC ) 

1 .  Alert  Review 

2.  Break  Engage 

3.  Cease  Fire 

4.  Engage  Interceptor 

5.  Engage  Missile 

6.  Position  Correction 
7* ••  Range  and  Bearing 
8.  Track  Review 
Intercept  Controller  (IC) 

1.  Accept  Engagement  Assignment 

2.  Cannot  Engage 

3.  Collision  Intercept  Trial  Geometry,  Request  for 

4.  Data  Readout 

5.  Down/Left,  Up/Right  (these  are  dual  function 

QABs ;  they  are  used  to  order  speed  decreases/increases 
or  port/starboard  turns) 

6.  Fuel  on  Board  Interceptor 

7.  Order  Sent 

8.  Position  Correction 

9.  Pursuit  Intercept  Trial  Geometry,  Request  for 

10.  Range/Magnetic  Bearing  (this  QAB  is  used  to  re¬ 
quest  a  readout  of  the  target  bearing  and  range 
i n  relation  to  the  interceptor) 

11.  Reposition 
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13.  Steady 

14.  Speed  Magnetic  Heading 
Track  Supervisor  (TRK  SUP) 

1.  Automatic  History  Display 

2.  Automatic  Offset 

3.  Course  and  Speed 

4.  Display  Accept  Remote 

5 .  Interchange 

6 .  Late  Detect 

7.  New  Track 

8.  Non-NT DS 

9.  Position  Correction 

10.  Navigation  Position  Data 

11.  Range  and  Bearing 

12.  Split 

13.  Track  History 

14.  x-y  coordinates 
Identification  Operator  (ID) 

1.  Airborne  Early  Warning  Aircraft 

2 .  Air 

3.  Assumed  Friend 

4.  Assumed  Hostile 

5.  ASW  Aircraft 

6 .  Friend 

7.  lie  lo 
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8. 
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9  . 

Interceptor 

•  • 

10. 

Reference  Point 

11. 

Sequen ce 

12. 

Strike  Aircraft 

13. 

S  u  r  f  a  c  e 

14. 

Track  History 

15  . 

Unknown 

Be  t 

actor /Tracker  (DET/TRK) 

1. 

Automatic  Track  History 

2  . 

Automatic  Offset 

3. 

Assign  Here 

4  . 

Late  Detect 

5  . 

New  Track 

6. 

Position  Correction 

7. 

Sequence 

8. 

Split 

(C)  In 

addition  to  the  QABs  listed  above,  each  operator  lias 

fixed  function  QABs  such  as  Drop  Track,  Function 

Code  entry. 

and  Enable  Ball  Tab. 

(C)  The 

enly  manual  task  performed  by  NTDS  console  operators 

tli at  is 

not  a  button  pushing  or  switching  action 

is  the  posi- 

t  i  on  i  li  g 

of  the  Ball  Tab,  which  is  done  Ivy  rolling 

the  Track 

Ball. 

Task  Pes 

evictions 

( U)  General  task  descriptions  for  the  six  major 

NTDS  func- 

tions  arc  given  below.  Detailed  task  descriptions  arc  pre- 

sented  in  Appendix  B . 
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for  evaluation  of  the  force  tactical  situation,  and  for  the 
combat  direction  of  force  weapons.  The  F IV C  is  responsible 
for  continuously  reviewing  and  reevaluating  the  tactical 
situation  and  ordered  engagements  for  making  changes  in  en¬ 
gagement  assignments  as  necessary.  In  contrast  to  conven¬ 
tional  (non-NTDS)  task  groups  where  the  OTC  usually  delegates 
the  duty  of  Force  AAW  Commander  to  a  subordinate  commander, 
the  NTDS  OTC  usually  exercises  this  responsibility  himself 
(through  a  senior  member  of  his  staff  acting  as  FWC) . 

(C)  Ship  Weapons  Coordinator  (SWC).  The  SWC  is  responsible 
for  the  combat  direction  of  own-shipfs  weapons.  SWC  directs 
engagements  of  own-ship’s  weapons  either  in  response  to  the 
Force  Weapons  Coordinator’s  orders  or  on  his  own  initiative. 

(C)  Intercept  Controller  ( IC /♦  The  IC’s  primary  responsi¬ 

bility  is  to  control  aircraft  on  intercept  and  other  type 
missions.  Usually  the  IC  acts  in  response  to  SWC  orders  but 
may  act  on  his  own  initiative  to  counter  an  immediate  threat. 

(C)  Track  Supervisor  (TRK  SUP).  The  Track  Supervisor  moni¬ 
tors  and  supervises  the  performance  of  all  own-ship  Input 
operators.  In  addition,  lie  is  responsible  for  maintaining 
gridlock,  monitoring  the  performance  of  Link  11  and  14,  and 
acting  as  the  Combat  Information  and  Detection  (CID)  Net 
communicator.  Me  also  acts  as  a  back-up  for  all  other  input 
operators . 

(C)  Identification  Operator  (ID).  The  ID  operator  is  respon 
sible  for  performing  that  portion  of  the  identification  task 
delegated  to  him  by  command  and  for  entering  the  identifica¬ 
tion  of  all  tracks  into  the  system.  The  identification  of  a 
given  track  is  determined  on  the  basis  of  (1)  Identification 
Friend  or  Foe /Selected  Identification  Feature  (IFF/SIF)  in¬ 
formation,  (2)  the  track’s  course,  speed,  and  altitude, 
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(3)  intel  1  j  gcjn’cej  dcj  ta  tn*c»  Vacgjetj' s  »es*p#i>s  ec  jt<>  ordered 

maneuvers,  •(*3)*  Ytu*?*:nt  *o  £>*J*r  a  V/  or?  •  t)  i*d  e*r  5  •  •  •  a?i*d  (*6)*  orders  re¬ 
ceived  from  the  Officer  in  Tactical  Command  (OTC) . 


(C)  Detector /Tracker  (DET/TRK).  The  primary  responsibilities 
of  the  DET/TRK  are  to  detect  targets,  enter  new  tracks  into 
the  system,  and  to  then  maintain  an  accurate  track  on  each 
track  in  his  assigned  sector  of  responsibility. 

(C)  The  tasks  required  of  the  NTDS  operators  perhaps  can  be 
better  appreciated  by  considering  the  sequence  of  events 
that  occur  with  respect  to  a  single  hostile  track  that  enters 
the  system.  Figure  2  shows  a  kind  of  operational  sequence 
diagram  of  the  operator  actions  from  the  search  for  and  detec¬ 
tion  of  a  target  to  the  final  event  of  its  destruction.  The 
situation  depicted  is  greatly  simplified,  because  there  are 
usually  many  other  tracks  in  the  system  at  given  times.  The 
events  occur  in  the  time  order  suggested  by  the  placing  of 
the  boxes  from  top  to  bottom  of  the  diagram,  though  no  times 
are  given.  The  total  time  available  from  track  entry  to  exit 
depends  on  such  factors  as  the  range  a  target  is  detected, 
its  course  and  speed,  and  its  weapon  release  point.  The 
diagram  is  described  in  detail  on  the  pages  following  Figure  2. 


Figure  2.  Di  aci/am  ,o/..NTD§  .Qpec5.tor..Ai:ticy'.s.  ... 
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Search 

(C)  The  diagram  depicts  Search  as  a  single  action  by  a  single 
operator.  Tn  reality,  search  is  a  continuing  activity  en¬ 
gaged  in  by  every  console  operator.  It  is  important  to  note 
that  as  the  overall  level  of  activity  increases  there  is  a 
consequent  decrease  in  both  the  time  available  for  search  and 
the  effort  devoted  to  it. 

(C)  NTDS  has  a  Detector  mode  of  operation.  Originally  one 
or  more  console  operators  were  assigned  to  this  mode  and 
assigned  the  single  task  of  search.  O'/er  the  years,  opera¬ 
tional  experience  has  led  fleet  users  to  the  conclusion  that 
it  is  not  necessary  to  have  ccnsoles/operators  devoted  ex¬ 
clusively  to  the  search  task.  The  standard  operating  pro¬ 
cedure  is  now  to  combine  the  roles  of  Detector  and  Tracker 
(DE  l’/TRK)  . 

De  te  ct 

(C)  Each  operator  may  see  the  same  radar  presentation.* 
Therefore,  any  operator  may  be  the  first  to  detect  a  new  piece 
of  video.  New  tracks  are  normally  entered  by  Input  operators, 
usually  the  TRK  SUP  or  the  DET/TRK,  but  Users  in  the  Utility 
Mode  may  also  enter  new  tracks. 

Enter  New  Track  (ENT) 

(C)  As  used  here,  ENT  includes  several  individual  actions. 

New  tracks  are  entered  into  the  system  in  the  following  manner 
When  an  operator  detects  a  new  piece  of  video,  he  enables  his 
Ball  Tab,  roUs  it  to  the  position  of  the  video,  aligns  the 


NTDS  ships  have  more  than  one  air-search  radar  plus  a  surface 
search  radar:.  Moreover,  .the  DET/TRKs  (usually  two  or  more) 
typically  have  their  radar  display  offset  to  effect  search 
sectors.  It  is,  however,  true  that  any  operator  can  see  the 
same  radar  presentation  as  any  other  operator. 
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tative  track  symbol  appears  on  each  Input  operator’s  PPI 
display  (but  not  on  the  User  consoles).  When  the  track  has 
been  updated,  Position  Corrected,  three  times,  it  becomes  a 
firm  track.  Firm  tracks  symbology  is  displayed  on  all  own- 
ship’s  consoles  and  is  transmitted  to  other  NTDS  ships  via 
Link  11.  A  track  number  is  automatically  assigned  to  each 
new  track  by  the  computer. 

(C)  If  72  seconds  elapse  between  updates  before  a  track 
becomes  a  firm  track,  it  is  auto  mail  callrj  dropped  by  the  sys¬ 
tem.  If  72  seconds  elapse  between  updates  after  a  track 
becomes  a  firm  track,  it  becomes  a  trouble  track.  Trouble 
tracks  are  indicated  by  blinking  scope  symbols.  This  blinking 
feature  alerts  the  operator(s)  that  the  track  has  not  been 
updated  for  some  time  (72  or  more  seconds)  and  that  it  should 
be  updated  as  soon  as  possible.  Trouble  tracks  do  not,  however, 
receive  any  special  sequencing  priority. 

(C)  The  NTDS  tracking  task  differs  from  normal  radar  tracking 
in  that  it  is  not  necessary  to  locate  the  track  manually 
(after  the  track  is  entered  initially).  The  series  of  events 
in  the  tracking  task  are  as  follows:  the  DET/TRK  presses  his 
Sequence  QAB;  this  places  a  track  symbol  in  close  control, 
the  Hook  symbol  appears  around  the  track  symbol;  the  DET/TRK 
checks  the  alignment  (displacement  if  any)  of  the  symbol  dot 
(e.g.,  /?0  with  the  center  leading  edge  of  the  video.  If  the 
dot  is  superimposed  on  the  center  leading  edge  of  the  video, 
the  DET/TRK  presses  his  Position  Correction  QAB.  The  Position 
Correction  action  enters  the  update  and  causes  automatic  se¬ 
quencing  to  take  place.  If  the  symbol  dot  is  not  superimposed 
with  the  center  leading  edge  of  the  video,  the  DET/TRK  presses 
the  Ball  Tab  Enable  QAB.  This  causes  the  Ball  Tab  symbol  to 
appear  in  the  center  of  the  Hook  symbol.  The  DET/TRK  then 
uses  his  Track  Ball  to  roll  the  Ball  Tab  to  the  center  leading 
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of  the  video,  to  be  entered  into  the  system.  Notice  that 
whether  or  not  it  is  necessary  to  correct  the  position  of 
the  track,  the  Position  Correction  QAB  is  used  to  enter  the 
track's  present  position  to  update  the  track. 

Identification 


(C)  The  identification  procedure  for  known  friendly  air¬ 
craft  is  straightforward.  The  ID  operator  places  a  track  in 
close  control;  this  can  be  accomplished  either  automatically 
or  manually.  He  enters  the  General  Purpose  Function  Code 
(  G  P  F  C )  for  IFF  interrogate,  then  presses  the  Function  Code 
button.  This  causes  the  IFF  equipment  to  interrogate  an 
area  centered  on  the  position  of  the  Hook  symbol;  that  is  to 
interrogate  the  track  in  close  control.  The  IFF  return  is 
displayed  on  the  UPA-50  IFF  display  panel.  The  code  displayed 
on  the  UPA-50  will  be  the  aircraft's  PIF  (Personal  Identifi¬ 
cation  Feature)  code  and  will  specifically  identify  its  parent 
carrier,  squadron,  and  side  number.  The  ID  operator  compares 
this  number  with  a  list  of  PIF  codes  for  the  friendly  air¬ 
craft  known  to  be  operating  in  the  area.  He  then  enters  the 
PIF  code  in  his  number  entry  dials  and  presses  his  Selected 
Identification  Feature  (SIF)  QAB.  Then,  using  the  appropriate 
QABs  ,  he  enters  the  track's  Class  (in  this  case,  "air");  its 
Category  (e.g.,  interceptor  AEW,  helo);  and  its  Identification 
(in  this  case,  "confirmed  friend").  This  identification  in¬ 
formation  becomes  associated  with  the  track  and  is  displayed 
on  every  operator's  PPI  in  the  form  of  track  symbols;  for 
example,  '  /\  '  for  'air  hostile,'  ' HI '  for  'air  unknown  ,  ' 

1  rrs '  for  'air  friendly.'  Amplifying  identification  informa¬ 
tion  can  be  called  up  for  display  on  the  DRO. 

(Cj  The  identification  of  tracks  other  than  those  known  to 
be  friendly  is  somewhat  more  involved.  Identification  friend 
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gates  to  his  subordinates  the  authority  to  identify  certain 

kinds  of  tracks,  generally  tracks  that  are  confirmed  friend, 
assumed  friend,  or  unknown.  He  does  not,  usually,  delegate 
authority  to  identify  tracks  as  assumed  or  confirmed  hostile. 


(C)  When  the  CO  is  immediately  available,  as  he  would  be 
during  General  Quarters,  his  retention  of  the  authority  to 
identify  tracks  as  hostile  creates  little  if  any  diffi¬ 
culty  or  delay.  When  the  CO  is  not  immediately  available, 
such  as  when  he  is  asleep  during  routine  night  steaming, 
failure  to  delegate  authority  to  identify  tracks  can  create 
problems.  To  partially  compensate  for  the  potential  delay 
inherent  in  this  situation,  each  ship  has  an  ID  SOP  (Iden¬ 
tification  Standard  Operating  Procedure)  which  establishes 
guidelines  to  be  used  when  the  CO  is  not  immediately  avail¬ 
able. 


(C)  If  the  ID  operator  is  unable  to  identify  a  track  using 
SIF/IFF  procedures  described  earlier,  he  informs  the  SWC 
and  TRK  SUP.  The  ID  operator  has  several  options  available 
to  him.  He  may  check  the  flight  schedule  to  determine 
whether  a  friendly  aircraft  is  supposed  to  be  where  the 
aircraft  in  question  is,  or  whether  the  aircraft  in  question 
is  flying  at  the  predesignated  course,  speed,  and  altitude 
given  in  the  flight  schedule.  He  can  request  the  Electronic 
Countermeasures  (ECM)  Supervisor  to  attempt  to  identify  the 
track.  He  may  attempt  to  establish  voice  communications 
with  the  aircraft.  If  he  is  successful  in  establishing  com¬ 
munications,  the  ID  operator  will  inform  the  pilot  that  his 
IFF  equipment  is  not  operating.  If  the  pilot  turns  on  his 
IFF  gear,  the  identification  procedure  reverts  to  the  routine 
SIF/IFF  procedure  described  earlier. 

(C)  If  the  IFF  equipment  does  not  come  on,  the  ID  operator 
may  ask  the  pilot  to  perform  a  prearranged  ordered  maneuver 


.2  7. 


•  •  •  • 


(a  sequentjaj  pa*itern»«cjf  jtuws)  /•'  (5r  3ie  way  cfe&tlto  conduct 

•••  ••••  •••  •  •••  •••  •••  •  •  ••••  •••  •  •  •• 

a  visual  check  of  the  unidentified  aircraft;  that  is,  have  a 

CAP  aircraft  intercept  the  unidentified  aircraft.  Or  the  ID 
operator  may  elect  to  lock-on  the  unidentified  aircraft  with 
own-ship's  fire  control  radar. 


(C)  It  is  important  to  note  that  the  ID  operator  does  not 
have  the  authority  to  initiate  any  of  the  latter  three  pro¬ 
cedures  on  his  own.  Before  proceeding  with  any  of  them,  he 
will  have  to  obtain  permission  to  do  so  from  the  SWC,  who 
may  in  turn  have  to  obtain  permission  from  the  CIC  Evaluator 
(the  senior  officer  on  watch  in  CIC)  who  may  have  to  obtain 
permission  from  the  CO. 


(C)  Either  the  SWC,  the  Evaluator,  or  the  CO  may  have  in¬ 
formation  of  an  intelligence  nature  that  is  not  available  to 
the  lower  echelons  of  the  command  structure. 


(C)  Assuming  that  any  or  all  of  these  procedures  are  ini¬ 
tiated,  any  result  of  other  than  confirmed  or  assumed  friend 
or  unknown  may  still  have  to  be  cleared  with  the  command 
structure  before  it  is  entered  into  the  system  and  thus  trans¬ 
mitted  over  the  data  link. 

(C)  Once  the  ID  is  transmitted  over  the  data  link,  the  Task 
Group  Commander,  actually  the  Force  Weapons  Coordinator  (FWC) , 
and  the  Force  ID  Operator,  will  repeat  some  or  all  of  the  above 
procedures  and  either  confirm  or  deny  own-ship's  ID. 


(C)  If  the  FWC/Force  ID  Operator  or  another  ship  disagrees 
with  own-ship's  ID,  an  ID  Conflict  is  said  to  exist.  ID 
conflicts  are  resolved  automatically  by  the  computer  in 
favor  of  the  most  positive  information;  for  example,  if  one 
ship  reports  assumed  friend  and  another  confirmed  friend, 
the  system  accepts  confirmed  friend.  If  the  system  cannot 
resolve  the  conflict,  it  is  resolved  manually  by  the  two 
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conflict  unconditionally. 

(C)  The  length  of  time  available  to  identify  a  track  depends 
on  the  tactical  situation.  The  "required  certainty  before 
action"  will  also  vary  with  the  tactical  situation.  It  would 
seem  apparent  that  the  longest  delays  and  the  greatest  "re¬ 
quired  certainty  before  action"  would  occur  at  night  during 
routine  situations,  the  very  time  when  the  threat  of  surprise 
attack  is  probably  greatest,  and,  therefore,  the  necessity 
for  quick  response  is  also  greatest. 

(C)  The  ID  operator  task  is  not  completed  when  he  assigns 
an  initial  ID  to  a  track.  The  ID  of  each  track  is  reviewed 
aperi odi ca 1  ly  for  as  long  as  it  remains  within  radar  range 
of  own-ship,  or  in  the  case  of  a  hostile  until  weapons  are 
fired.  Ideally  the  ID  of  a  hostile  would  be  reviewed  just 
prior  to  each  of  the  following  actions:  Target  Selection, 
Accept  Assignment,  Accept  Engagement,  and  Completion  of 
Intercept . 

Identification  Confirm 

(C)  The  SWC ,  Force  ID  operator,  and  the  FWC  will  check  the 
identification  of  each  track  to  either  confirm  or  deny  the 
ID  entered  by  the  ID  operator.  The  check  by  each  of  these 
operators  will  consist  of  looking  for  obvious  errors  or  of 
applying  additional  information  not  available  to  the  other 
operators.  The  ID  Confirmation  check  will  be  repeated 
aperiodical ly  and  for  hostile  tracks  up  to  the  moment  of 
firing  a  weapon. 

Combat  Information  and  Detection  (CID)  Net  Report 

(C)  The  TRK  SUP  reports  to  the  FWC,  using  the  Combat  Informa¬ 
tion  and  Detection  (CID)  voice  radio  reporting  circuit,  the 
initial  track  data  for  each  track  that  is  not  identified  as 
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this  informat*i6ir*vl*a  thfc  •d&ta*,liti,k  ,»*thi»s»*rep*ort  is*#simply  an 
alerting  and  confirming  message. 

Select  Target 


(C)  Target  selection  may  be  accomplished  either  at  the  force 
level  or  at  the  own-ship  level.  The  FWC  is  primarily  con¬ 
cerned  with  the  defense  of  the  force  as  a  whole,  whereas  the 
SWC  is  primarily  concerned  with  the  defense  of  his  own-ship. 
The  objective  of  the  FWC  and  the  SWC(s)  is  to  engage  and 
destroy  as  many  enemy  aircraft  as  expeditiously  as  possible 
and  as  far  as  possible  from  the  Vital  Area  (the  position  of 
the  protected  force).  A  corollary  objective  is  to  minimize 
the  length  of  time  a  particular  weapons  system  (interceptor 
or  missile)  is  engaged  with  a  particular  target. 


(C)  Targets  are  selected  on  the  basis  of  their  threat  to 
the  force  or  to  own-ship.  Threat  value  is  based  on  the 
target's  ID  and  its  range,  course,  speed,  and  altitude. 

The  system  computes  a  threat  number  for  all  system  tracks 
except  for  those  identified  as  Confirmed  Friend.  An  emer¬ 
gency  track  alert  is  generated  and  presented  to  FWC  and  SWC 
whenever  a  track  threat  number  reaches  a  predetermined  level. 
The  SWC  or  the  FWC  can  ignore  this  track  temporarily  (by 
sequencing  away  from  it),  but  the  alert  will  be  regenerated 
each  time  the  threat  number  increments. 


(C)  The  FWC  or  SWC  select  targets  by  reviewing  their  PPI 
and  DRO  presentations.  They  can  Sequence  to  all  system 
tracks  or  to  all  system  air  tracks  as  they  choose  (the 
choice  is  effected  by  a  GPFC  action).  As  each  track  is 
placed  in  close  control,  the  tracks'  characteristics  are 
displayed  in  the  DRO. 

Assign  Weapon 

(C)  Weapon  selection  is  also  the  responsibility  of  the  FWC 
or  the  SWC.  The  weapon  selection  strategy  is  based  on  the 
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ceptors  (as  used  here,  range  refers  to  the  initial  position 
of  the  interceptors,  not  to  their  tactical  characteristics) 
and  long-  and  short-range  SAMs  (in  this  instance  range  does 
refer  to  the  missile  characteristics  but  may  also  refer  to 
the  position  of  the  missile  ship).  The  preferred  weapon 
is  the  weapon  that  can  engage  the  target  at  the  greatest 
distance  from  the  force  or  own-ship.  Thus  the  long-range 
interceptor  would  be  the  first  choice,  the  short-range 
interceptor  the  second  choice,  and  so  on.  This  scheme  has 
the  advantage  of  not  only  engaging  targets  at  the  greatest 
distance  possible,  but  also  of  providing  successive  lines 
of  defense  in  case  the  enemy  is  not  destroyed  by  the  pre¬ 
ceding  line  of  defense. 

(C)  The  FWC  makes  a  weapon  assignment  by  Hooking  the  target 
and  Ball  Tabbing  either  the  interceptor  or  the  ship  desig¬ 
nated  to  conduct  the  intercept  and  then  pressing  his  Engage 
Interceptor  QAB.  This  action  causes  a  pairing  line  to  be 
drawn  on  the  FWC's  PPI  between  the  target  and  the  inter¬ 
ceptor  and  to  be  transmitted  over  the  data  link.  This  action 
also  generates  a  Flag  Order  Alert  at  the  S IV C  console  of  the 
ship  controlling  the  designated  interceptor. 

(C)  The  procedures  followed  by  the  F1VC  when  he  selects  a 
missile  are  essentially  the  same  as  when  he  selects  an  in¬ 
terceptor.  The  FWC  Hooks  the  target.  Ball  Tabs  the  missile 
ship,  and  presses  his  Engage  Missile  QAB.  Again  a  pairing 
line  is  drawn  on  his  scope  and  transmitted  over  the  data 
link,  along  with  a  Flag  Order  Alert. 

Accept  Assignment 

(C)  A  buzzer  sounds  to  inform  the  S1VC  that  he  has  received  a 
Flag  Order  Alert.  The  Flag  Order  Alert  light  on  his  Alert 
Panel  also  lights  up.  He  presses  his  Alert  Review  QAB  to 
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nated  target  (to  place  the  target  in  close  control)  and  to 
display  a  pairing  line  between  the  target  and  the  selected 
weapon . 

(C)  If  for  some  reason  SWC  is  unable  to  engage  the  target 
(e.g.,  if  his  interceptor  does  not  have  sufficient  fuel  to 
complete  the  intercept),  SWC  responds  to  the  Flag  Order  by 
entering  the  GPFC  for  Cannot  Comply.  If  he  can  engage  the 
target,  he  proceeds  to  assign  weapons  to  the  target. 

Assign  Inter  cep  tor /Mis  site 


(C)  The  procedure  used  by  SWC  to  assign  interceptors  and 
missiles  is  similar.  The  SWC  Hooks  the  target,  Ball  Tabs 
the  interceptor,  and  presses  the  Engage  Interceptor  QAB  or 
Engage  Missile  QAB,  as  appropriate.  It  is  not  necessary 
for  SWC  to  Ball  Tab  own-ship  when  he  elects  to  engage  a  tar¬ 
get  with  missiles  since  the  system  knows  that  own-ship's  SWC 
only  has  control  over  own-ship's  missiles. 

(C)  This  action  generates  a  Target  Assigned  alert  at  the 
IC  or  FCSC  (Fire  Control  System  Coordinator)  console.  If 
for  some  reason  the  IC  or  FCSC  is  unable  to  engage  the  tar¬ 
get,  they  press  their  Cannot  Engage  QAB  which  generates  a 
Cannot  Engage  Alert  at  the  SWC  console.  At  this  point  SWC 
may  select  an  alternate  weapon,  if  he  has  one  available,  or 
he  may  inform  FWC  that  he  is  unable  to  engage  the  target. 

FWC  would  in  this  latter  case  attempt  to  assign  an  alternate 
force  weapon. 

Conduct  Intercept 


(C)  Based  on  the  geometry  of  the  situation,  the  relative 
positions,  courses,  speeds,  altitudes,  and  ranges  of  the 
target  and  interceptor,  the  IC  operator  elects  to  conduct 
either  a  Pursuit  or  a  Collision  intercept.  If  he  has 
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which  causes  Trial  Geometry  to  be  displayed  on  his  PPI; 

Trial  Geometry  appears  as  lines  originating  from  the  inter¬ 
ceptor  and  target  symbols  with  the  point  where  they  cross 
indicating  the  point  of  intercept,  assuming  the  target  con¬ 
tinues  at  its  present  course  and  speed.  The  line  drawn  from 
the  interceptor  also  represents  a  system  computed  course- 
to-steer  recommendation.  If  the  geometry  of  the  situation 
is  such  that  the  intercept  cannot  be  completed,  Poor  Situa¬ 
tion  is  displayed  on  the  IC's  DRO.  The  IC  may  be  able  to 
"save”  the  intercept  by  increasing  the  speed  of  the  inter¬ 
ceptor  (the  initial  trial  geometry  is  calculated  at  an  arbi¬ 
trary  speed  of  O.S  MACH--less  than  the  interceptor's  maximum 
speed).  If  the  intercept  cannot  be  effected,  the  IC  informs 
the  SWC  who,  in  turn,  informs  the  FWC,  who  selects  an  alter¬ 
nate  weapon  to  engage  the  target,  if  the  SWC  or  IC  have  not 
already  done  so. 


(C)  Assuming  the  intercept  can  be  completed  and  assuming 
the  trial  geometry  recommendation  is  acceptable,  the  IC 
sends  a  course  and  speed  order  to  the  interceptor.  Once  the 
order  has  been  sent,  the  IC  presses  his  Order  Sent  QAB, 
which  causes  the  interceptor  symbol  to  change  to  the  engaged 
interceptor  symbo 1 . 


(C)  Orders  are  sent  tc  the  interceptors  by  voice  radio  or 
by  automatic  data  link.  Link  4A.  When  voice  radio  is  used, 
the  IC  transmits  a  control  order  and  then  presses  Order  Sent. 
When  Link  4A  is  used,  the  control  order  is  initiated  by  the 
pressing  of  the  Order  Sent  QAB. 


(C)  When  the  intercept  is  completed,  the  IC  informs  SWC  of 
its  success  or  failure  and  presses  Cannot  Engage  to  indicate 
that  his  interceptor  is  available  for  another  assignment. 


Select  Subsequent  Targets 

(C)  It  is  the  responsibility  of  the  FWC,  SWC,  and  IC  to 
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as  quickly  and  judiciously  as  possible  after  initial  engage¬ 
ments  are  completed.  To  do  this,  it  is  imperative  that 
subsequent  targets  be  selected  during  engagements  and  not 
after  they  are  completed. 

Assign  Subsequent  Target 


(C)  The  procedures  for  assigning  subsequent  targets  are 
identical  to  the  procedures  used  for  assigning  initial  tar¬ 
gets  . 

Engage  Subsequent  Target 

(C)  The  procedures  used  to  engage  subsequent  targets  are 
identical  to  the  procedures  used  during  initial  engagement. 

TRK  SUP  Monitoring  Task 

(C)  The  diagram  depicts  the  four  major  aspects  of  the  TRK 
SUP's  monitoring  task:  Monitor  TRK  Performance,  Check 
Navigational  Position,  Check  Gridlock,  and  Monitor  Data  Link 
Performance.  As  indicated  by  the  diagram,  these  tasks  are 
not  directly  related  to  target  engagement.  These  tasks  are 
continuous,  starting  before  t arget - re  1  at ed  activity  commences 
and  continuing  on  after  t arget - re lated  activity  has  been 
comp leted . 
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(U)  The  development  of  an  operational  data  bank  for  command- 
and-control  systems  must  involve  consideration  of  how  to  col¬ 
lect  reliable  and  valid  performance  data.  Some  alternative 
methods  are  record  keeping  of  performance  errors  and  times  by 
operational  personnel,  observations  by  trained  observers,  di¬ 
rect  recording  of  overt  performance  events  by  hooking  equipment 
into  a  system,  and  judgments  of  performance  by  experienced  op¬ 
erational  personnel.  Two  methods  have  received  most  attention 
in  this  study:  the  per f orman ce- j udgment  and  di r e c t - re  cor din g 

methods.  The  feasibility  of  obtaining  reliable  judgments  of 
performance  errors  for  a  particular  operator  task  was  evaluated 
among  experienced  system  operators.  The  hardware  for  direct 
recording  of  system  events,  the  Data  Recording  System  (DRS) , 
was  developed  by  NELC;  and  the  software  requirements  for  inter¬ 
preting  the  recordings  were  specified  jointly  by  NELC  and  HFR. 

Collection  of  Performance  Judgment  Data 

(C)  The  purpose  of  collecting  performance  judgment  data  was 
to  determine  if  experienced  operational  personnel  could  agree 
on  an  ordering  of  the  relative  frequency-of -occurrence  and 
importance  of  errors  committed  by  the  TRK  SUP.  The  TRK  SUP 
task  was  selected  for  study  because  his  role  is  central  in  the 
NTDS  and  other  operators  are  aware  of  his  pe r f or mance - -  1 i mi t e d 
access  to  enough  qualified  operators  did  not  permit  obtaining 
judgments  of  the  TRK  SUP  task  from  TRK  SUPs  only. 

(C)  Procedure .  A  preliminary  list  of  some  50  performance 
errors  that  the  TRK  SUP  possibly  could  make  was  developed  from 
task  analysis  information.  Through  interviews  with  FAAWTC 
instructors  and  shipboard  personnel,  the  list  was  reduced  to 
35  errors  that  were  judged  to  be  important  and  to  occur  with 
some  frequency. 

(C)  Error  statements  were  developed  and  a  pilot  test  was  con¬ 
ducted  with  14  FAAIVTC  instructors.  Their  task  was  to  rank  the 
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frequency  o f»Iocowr»i»8n cel  i*i«le  r.^tWe eJ*if^t.«>ue<>i on ai  sets  , 
different  levels  of  track  activity.  Their  comments  were 
solicited  about  the  format  of  the  statements  and  the  diffi¬ 
culty  of  the  ranking  tasks.  The  subjects  indicated  that  th 
did  not  find  the  tasks  difficult,  but  there  was  substantial 
disagreement  among  them  in  the  ordering  of  statements. 


(C)  Based  on  the  pilot  test  results, 
statements  was  further  reduced  to  20, 
many  were  modified.  The  following  20 
used  in  subsequent  studies. 


the  list  of  error 
and  the  formats  of 
error  statements  were 


1.  TRK  SUP  FAILS  TO  ESTABLISH  OWN-SHIP'S  TRUE 
GEOGRAPHIC  POSITION  TO  WITHIN  ±  500  YARDS. 

2.  TRK  SUP  FAILS  TO  CLEAR  GRIDLOCK  PADS  PRIOR  TO  HIS 
SHIP  ASSUMING  ROLE  OF  GRIDLOCK  REFERENCE  SHIP. 

3.  TRK  SUP  FAILS  TO  DIRECT  TRACKER  TO  CHANGE  RANGE 
SCALES  WHEN  TACTICAL  OR  ENVIRONMENTAL  CONDITIONS 
SO  DICTATE. 

4.  TRK  SUP  FAILS  TO  DROP  OLD  TRACKS  WITHIN  5  MINUTES 
AFTER  THEY  HAVE  FADED  FROM  THE  SCOPE. 

5.  TRK  SUP  FAILS  TO  DETECT  NEW  PIECES  OF  VIDEO 
(ASSUMES  A  SITUATION  WHEN  THE  DET /TRK  HAS  ALSO 
FAILED  TO  DETECT  THIS  NEW  PIECE  OF  VIDEO). 

6.  TRK  SUP  FAILS  TO  RECOGNIZE  AND  DROP  INVALID  TRACKS 

7.  TRK  SUP  FAILS  TO  RECOGNIZE  AND  ELIMINATE  DUAL 
TRACK  DESIGNATIONS. 

8.  TRK  SUP  FAILS  TO  RESOLVE  ALL  TRACK  CONFLICTS 
BEFORE  ENTERING  AN  ESTABLISHED  DATA  LINK. 

9.  TRK  SUP  FAILS  TO  NOTIFY  ALFA  WHISKEY  OF  OWN-SHIP'S 
UNCONTROLLED  EXIT  FROM  DATA  LINK  WITHIN  1  MINUTE 
OF  EXIT. 

10.  TRK  SUP  FAILS  TO  CHECK  THE  PERFORMANCE  OF  THE 
DATA  LINK. 

TRK  SUP  FAILS  TO  OBTAIN  A  SATISFACTORY  GRIDLOCK 
"FIT"  WITHIN  5  MINUTES. 


1 1 . 


12. :  W.5UCP  F/Ii ls: T(3  Use  ‘the  5)/U.ren|  tUree»-b«jtton 

•.^C5’I(5N*.P41(3g41.D&*ff3  •1*0*  H-AN*D  •&V$R  Ti^AC^fl NO* RESPON¬ 
SIBILITY  FOR  TRACKS  THAT  HAVE  FADED  FROM  HIS 
SCOPE . 

13.  TRK  SUP  FAILS  TO  RECOGNIZE  AND  CORRECT  EXCESSIVE 
GRIDLOCK  ERROR. 

14.  TRK  SUP  SPENDS  TOO  MUCH  TIME  TRACKING  AND  NOT 
ENOUGH  TIME  ATTENDING  TO  HIS  SUPERVISORY  TASK. 

15.  TRK  SUP  FAILS  TO  CHECK  OWN-SHIP'S  NAVIGATION 
POSITION  BEFORE  MAKING  GRIDLOCK  CORRECTIONS. 

16.  TRK  SUP  FAILS  TO  RECOGNIZE  THAT  A  LOWER  LEVEL  OF 
TRACKER  PERFORMANCE  IS  ACCEPTABLE  WHEN  TRACKERS 
ARE  OPERATING  AT  OR  NEAR  CAPACITY. 

17.  TRK  SUP  FAILS  TO  USE  A  MUTUAL  TRACK  WITH  A 
TRACK  QUALITY  OF  7  (OR  THE  HIGHEST  TQ  AVAILABLE) 

WHEN  ESTABLISHING,  CHECKING,  OR  CORRECTING 
GRIDLOCK. 

18.  TRK  SUP  FAILS  TO  DETECT  AND  CORRECT  OWN-SHIP'S 
NAVIGATION  ERROR  WHEN  IT  EXCEEDS  1000  YARDS. 

19.  TRK  SUP  FAILS  TO  REMAIN  COGNIZANT  OF  THE  TRACK¬ 
ING  PERFORMANCE  OF  HIS  TRACKERS  AND  TO  TAKE 
APPROPRIATE  CORRECTIVE  ACTION  WHEN  NECESSARY. 

20.  TRK  SUP  MAKES  A  MECHANICAL  ERROR  SUCH  AS  IN¬ 
ADVERTENTLY  ACTIVATING  THE  BALL  TAB,  MISREADING 
A  DRO  FORMAT,  ENTERING  THE  WRONG  FUNCTION  CODE 
(00730  INSTEAD  OF  00740),  ETC. 

(U)  Judgment  data  were  collected  from  subjects  on  two  NTDS 
ships:  24  on  the  USS  GRIDLEY  (D LG  21)  and  24  on  the  USS 

JOUETT  (DLG  29).  The  subjects  represented  the  following  opera 
tor  functions:  SWC,  IC,  TRK  SUP,  ID,  and  DET /TRK  (the  CO  of 
one  ship  participated). 

(U)  The  error  statements  were  typed  on  separate  cards,  and 
the  subjects  were  instructed  to  rank  the  statements  on  im¬ 
portance  and  frequency  under  two  instructional  sets,  a 
"routine1’  situation  with  few  tracks  in  the  system  and  a  "Gen¬ 
eral  Quarters1’  situation  with  many  tracks  in  the  system.  Thus 
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conditions  were  counterbalanced  so  that  the  order  of  condi¬ 
tions  was  not  the  same  for  each  subject.  The  subjects  were 
allowed  to  take  as  much  time  as  they  needed  for  each  ranking 
t  as  k  . 


(C)  Results .  Again,  the  subjects  claimed  they  had  little 
difficulty  with  the  ranking  tasks.  But  there  was  wide  dis¬ 
agreement  among  subjects  on  rank  positions  of  the  error 
statements  for  both  importance  and  frequency  of  occurrence. 

The  judgments  were  not  reliable  in  terms  of  in t er- s ub j e ct 
agreement . 

(C)  The  mean  rank  positions  for  each  statement  did  indicate 
that  discriminations  ’were  being  made,  in  spite  of  subject  dis¬ 
agreement.  For  example,  the  mean  ranks  for  frequency  of  oc¬ 
currence  under  routine  conditions  varied  from  about  6  to  about 
14  on  both  ships.  Similar  variations  were  observed  under  the 
other  ranking  conditions.  But  the  correlations  between  ships 
of  the  mean  ranks  for  the  corresponding  ranking  conditions 
were  essentially  zero.  The  judgments  were  not  reliable,  in 
terms  of  inter-group  agreement. 

(C)  Conclusions .  The  results  of  these  studies  of  error 
statement  ranking  do  not  encourage  the  judgmental  data  col¬ 
lection  method.  But  there  may  be  some  good  reasons  for  the 
lack  of  agreement  between  operators  and  between  ships,  other 
than  that  the  method  does  not  work. 


(C)  The  subjects  were  not  trained  observers,  even  though  they 
were  experienced  operators.  Perhaps  most  important,  they  were 
not  ’’error  conscious.”  In  interviews  conducted  after  the  judg¬ 
ment  sessions,  most  subjects  viewed  the  NTDS  as  a  ’’great 
system”  with  few  faults.  And,  though  they  were  directly  asked, 
none  of  the  subjects  identified  an  additional  error  to  the  20 
given  them  (in  spite  of  the  50  or  so  errors  that  were  iden¬ 
tified  earlier).  Although  errors  do  occur,  their  consequences 


••  •  •  •••  •••• 
•  •  •  •  •  • 

•  •  •  •  •  •  • 

•  •  •  •  •  •  • 

•  ••  •  •••• 


•  •  •  • 
•  •  • 

•  •  •  • 


«  • 

•  • 

•  •  • 


•  •  • 
•  •  • 
•  • 

•  • 


•  •  •  • 

•  •  •  •• 

•  •  •  •  •  i 

•  •••  •  «  m« 


• • •  Itti 


•  •  • 


may  not  be  serious  because  redundancies  in  the  system  permit 
timely  corrections.  Such  errors  may  not  be  perceived  as  errors 
at  ail;  or  if  they  are  they  may  not  be  perceived  to  be  im¬ 
portant.  If  observers  are  not  flalerted,f  to  error  occurrence, 
it  is  not  likely  they  can  make  reliable  judgments  about  error 
characteristics . 


(U)  Although  the  particular  judgmental  method  of  data  col¬ 
lection  used  "failed”  in  this  instance,  there  still  remains 
a  requirement  for  judgmental  data  of  operational  performance. 
This  is  particularly  true  of  the  decision-making  behaviors 
occurring  between  overt  responses  that  cannot  be  directly 
recorded  or  observed.  The  only  source  of  that  data  is  the 
decision  maker  himself.  The  task  remains  to  devise  methods 
to  collect  decision-making  data  in  a  format  suitable  for  an 
operational  data  bank. 

NELC  Data  Recording  System 

(U)  The  NELC  Data  Recording  System  (DRS)  has  been  designed 
to  automatically  record,  in  real  time,  events  that  occur  in 
the  NTDS . 

(C)  Monitoring  Capabilities .  A  single  DRS  is  capable  of 
monitoring  all  of  the  operator  actions  from  fifteen  NTDS  con¬ 
soles.  All  of  the  fifteen  consoles,  or  any  combination 
thereof,  may  be  individually  selected  at  the  DRS  front  panel 
controls.  All  of  the  Quick  Action  Buttons  (QAB)  and  function 
codes  from  each  individually  identified  operator  console  can 
be  recorded.  Of  the  42  available  function  codes,  26  can  be 
individually  included  or  excluded  during  data  recording,  and 
the  remaining  16  are  always  recorded  by  the  DRS.  In  addition 
to  recording  operator  actions,  the  DRS  records  the  track 
numbers  associated  with  each  action  and  the  system  and  clock 
time  of  each  action.  The  illegal  actions  taken  by  each  opera¬ 
tor  are  also  recorded. 

(U)  Shipboard  Installation .  The  Data  Recording  System  (DRS) 
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is  contained  in  two  semi-portable  cabinets.  The  DRS  can  be 
temporarily  installed  aboard  ship  in  a  few  minutes.  The  DRS 
uses  115  volt,  60  Hz  power  and  interfaces  with  the  NTDS  at 
the  Pulse  Amplifier/Symbol  Generator  (Central  Pulse  Amplifier-- 
CPA).  Data  acquisition  is  accomplished  without  disturbing  the 
integrity  of  the  NTDS:  no  cable  disconnections,  no  signal 
loading,  and  no  use  of  the  ship  computer. 


(U)  Data  Recorded.  The  following  data  are  recorded  by  the 
DRS  and  stored  on  magnetic  tape: 

1.  Identification  of  each  console. 

2.  Mode  of  each  console. 

3.  Identification  of  each  quick  action  button. 

4.  Identification  of  each  function  code. 

5.  Content  of  each  function  code. 

6.  Time  of  each  action  (QAB  or  GPFC). 

7.  Link  II  track  numbers. 

8.  Own-ship  track  numbers  (CTSL- - Central  Track 
Stores  Locator). 

9.  Identification  of  each  console  at  which  each 
operator's  actions  take  place. 

10.  Number  of  illegal  actions  per  console. 

11.  Identifier  information  (date,  time,  ship, 
observer,  etc.). 

12.  x-y  coordinates  and  range  of  track. 


(U )  Observer  Recording.  An  on-board  observer  or  observer  team 
is  viewed  as  an  integral  part  of  the  DRS  concept.  The  observer 
will  note  the  presence  and  levels  of  situational  variables, 
performance  characteristics,  and  the  like.  The  observer  data 
will  be  used  to  interpret  and  order  the  events  recorded  by  the 
DRS.  Personnel  at  NELC  have  suggested  the  following  list  of 
variables  that  might  be  observed. 
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Ship  class 

a.  CVA 
b  .  D LG 
c.  Conversion 

Sea  state/Weather 

Personal  stress  factors 

a.  Time  on  station 

b .  Time  on  w at ch 

c.  Watch  schedule 

(1)  Sleep  cycle 

(2)  Meal  cycle 

d.  Operational  situation 

(1)  Independent  exercise 

(2)  Multiple  unit  exercise 

(3)  Hostile  are  a 

(a)  Routine  ops 

(b)  Special  situation  (alert) 

(4)  General  Quarters 

(5)  Regular  underway  watch 

e.  Relations  with  supervisors 
d.  Relations  with  peers 

Training  factors 

a.  Formal  school  training 

b.  On-the-job  training 

c.  Operational  experience 

(1)  Conventional  CIC 

(2)  NTDS 

d.  Deployments 
Personal  history 

a.  Time  in  service 
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b. 

Time  in  rate/ grade 

r* 

Age 

d. 

Education 

6. 

Team  factors 

a . 

Time  together  as  a 

b. 

Newest  member 

c . 

Pull  team 

d. 

Deployed  as  team 

e  . 

Previous  duties  in 

7. 

Equipment  factors 

a . 

Sens  ors 

(1)  Radar 

(a)  Equipment  not  peaked  up/inoperative 

(b)  Inversion  layer  present 

(c)  Heavy  fog  or  cloud  cover 

(2)  ECM 

(3)  SIF/IFF 

b.  NTDS 


(1)  Alignment  error  between  radar(s)  and 
cons  oles 

(21  Alignment  errors  among  consoles 

(3)  Dropped  program 

(4)  Restart  program 

(5)  Console (s)  inoperative 

(6)  Mode(s)  inoperative 

8.  Operators*  judgments  concerning  exercise/operation 
difficulty  and  team  performance 


a.  Was  the  exercise  routine  with  regards: 

(1)  Number  of  friendly  tracks 

(2)  Number  cf  hostile  tracks 

(3)  Normal  NTDS  AAW  procedures 
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(4) 

Radar  performance 

(5) 

NTDS  equipment  performance 

b.  How 

well  the  team  performed: 

(1) 

Very  well 

(2) 

Better  than  average 

CD 

Average 

(4) 

Below  average 

(5) 

Not  well 

c .  Was 

the  team  unusually 

CD 

Bored 

(2) 

Tired 

(u)  Data  Reduction .  The  data  is  recorded  on  tape  in  a  format 
to  match  the  input  requirements  of  the  particular  computer  that 
will  be  used  for  the  analysis.  The  first  unit  is  compatible 
with  an  IBM  360  computer.  The  first  output  is  an  English 
language  listing  of  the  data  as  recorded,  decoded  to  the  ap¬ 
plicable  NTDS  software.  An  analyst  then  adds  to  the  raw  data 
all  of  the  observer  data  accompanying  the  recording  from  the 
ship.  The  augmented  list  is  then  re-run  through  the  computer 
to  produce  a  permanent  Input  Data  List  which  will  become  part 
of  an  ever-increasing  data  file.  All  sorting,  statistical 
summaries  and  exercise  reconstructions  will  be  produced  from 
the  Input  Data  Lists. 
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DEVELOPMENT  OF  A  TAXONOMY  OF  HUMAN  PERFORMANCE 

(U)  One  of  the  more  important  characteristics  of  an  opera¬ 
tional  data  bank  is  the  level  of  description  of  task  per¬ 
formance.  And  the  level  of  description  is  largely  determined 
by  the  scheme  used  to  classify  task  performance.  Task  per¬ 
formance  may  be  classified  at  a  relatively  molecular  level, 
such  as  in  terms  of  the  psychomotor  responses  required  in  a 
sequence  of  button-pushing  actions;  or  at  a  relatively  molar 
level ,  such  as  in  terms  of  the  task  functions  served  by  a 
sequence  of  responses.  Which  classification  scheme  is  "bette 
depends  entirely  on  how  it  is  to  be  used.  If  one  scheme 
"works provides  useful  information,  in  a  given  application, 
then  it  is  "better"  than  a  scheme  that  does  not. 

(U )  The  notion  that  one  can  develop  a  taxonomy,  similar  to 
those  found  in  the  biological  and  physical  sciences,  of  human 
performance  is  probably  illusory--if  by  taxonomy*  we  mean 
'classification  in  terms  of  essential  characteristics.'  What 
is  "essential"  in  one  situation  may  not  be  in  another.  The 
best  one  can  hope  for  is  to  develop  a  useful  taxonomy. 

(U)  There  are  four  major  requirements  for  a  useful  taxonomy 
of  human  performance: 

1.  That  the  terms  be  exhaustive;  that  no  other  terms 
are  needed  to  describe  task  performance. 

2.  That  the  level  of  description  implied  by  the 
terms  be  appropriate  in  the  situations  where 
the  taxonomy  is  applied. 

3.  That  the  user  of  the  taxonomy  be  taken  into 
account;  that  the  taxonomy  be  an  effective  com¬ 
munication  device. 

4.  That  the  common  or  special  connotations  of  the 
terms  of  the  taxonomy  be  taken  into  account; 

one  should  both  take  advantage  of  well-established 
meanings  of  terms  and  be  careful  not  to  interfere 
with  communication  by  redefining  terms. 
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(U)  Several  taxonomies  were  reviewed  in  the  course  of  this 
study.  The  one  that  seemed  best  to  apply  to  command-and- 
control  systems  is  the  taxonomy  developed  by  Miller  (1971). 

One  of  his  purposes  in  developing  the  taxonomy  corresponded 
to  one  of  our  purposes:  to  communicate  with  engineers.  His 

terms  were  selected  with  that  purpose  in  mind.  Miller's  taxon¬ 
omy,  which  he  called  a  "systems  task  vocabulary,"  and  his 
simplified  description  of  each  term  is  given  below. 


TERM 

MESSAGE 

INPUT  SELECT 
FILTER 

QUEUE  TO  CHANNEL 

DETECT 

SEARCH 

IDENTIFY 

CODE 

INTERPRET 

CATEGORIZE 

TRANSMIT 

STORE 

SHORT  TERM  STORAGE 
(BUFFER) 

COUNT 

COMPUTE 

DECIDE/SELECT 

PLAN 

TEST 

CONTROL 

EDIT 

DISPLAY 


SIMPLIFIED  DESCRIPTION 

A  collection  of  symbols  sent  as  a 
meaningful  statement. 

Selecting  what  to  pay  attention  to  next. 

Straining  out  what  does  not  matter. 

Lining  up  to  get  through  the  gate. 

Is  something  there? 

Looking  for  something. 

What  is  it  and  what  is  its  name? 

Translating  the  same  tiling  from  one  form 
to  another. 

What  does  it  mean? 

Defining  and  naming  a  group  of  things. 

Moving  something  from  one  place  to 
another. 

Keeping  something  intact  for  future  use. 

Holding  something  temporarily. 

Keeping  track  of  how  many. 

Figuring  out  a  1 o gi cal /mathemat i cal 
answer  to  defined  problem. 

Choosing  a  response  to  fit  the  situation. 
Matching  resources  in  time  to  expectations. 

Is  it  what  it  should  be? 

Changing  an  action  according  to  plan. 

Ar rangin g/ corre ct i n g  things  according  to  rules. 
Showing  something  that  makes  sense. 
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TERM  SIMPLIFIED  DESCRIPTION 

ADAPT/LEARN  Remembering  new  responses  to  a  repeated 

situation . 

PURGE  Getting  rid  of  the  dead  stuff. 

RESET  Getting  ready  for  some  different  action. 

(U)  In  developing  our  taxonomy >  we  have  leaned  heavily  on 
Miller’s.  Some  of  his  terms  have  been  omitted,  some  have 
been  combined,  and  some  new  ones  have  been  added.  The  taxon¬ 
omy  that  is  presented  below  is  viewed  as  a  preliminary  one 
whose  usefulness  remains  to  be  determined.  It  has  been  eval¬ 
uated  by  HFR  staff  engineers,  but  a  more  formal  evaluation 
and  test  of  its  application  is  required. 

A  Taxonomy  of  Human  Performance 

1.  Message 

(U)  Definition .  ’Message’  stands  for  ’a  pattern  of  symbols 
or  signals  that  activates  (or  could  activate)  a  process  that 
results  in  a  useful  system  response.' 

(U)  Comment .  Miller  said,  "the  concept  of  message  may,  like 
stimulus  in  psychology,  be  a  fundamental  one”  (p.  23).  He 

suggested  that  the  term  ’message’  may  not  be  formally  defined 
in  a  descriptive  system,  such  as  this  one,  but  rather  would 
gain  its  meaning,  by  example,  from  the  context  in  which  it  is 
used.  Indeed,  the  definition  given  above  conveys  little  about 
what  a  message  is,  without  exemplification.  Messages  in  the  man- 
machine  systems  we  are  interested  in  may  occur  in  any  one  of 
these  formats : 

a.  A  language  symbol  pattern.  The  meaning  of  a  message 
in  language  symbols  is  determined  by  rules  of 
grammar,  semantics,  and  reference.  For  example, 

"You  are  too  far  to  the  right  of  the  target”  lias 
meaning  in  a  given  context  to  those  who  understand 
English.  The  message  may  be  abbreviated  (’’right” 
for  the  above  message),  but  its  meaning  still  depends 
on  language  rules.  The  abbreviation,  of  course, 
stands  for  the  entire  message.  Language- symb o 1 
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messages  may  be  commun.i  cations  from  man  to  man, 
such  as  voice  commands,  or  from  machine  to  man, 
such  as  a  computer  printout  in  English, 


b.  A  non-language  symbol  pattern.  The  meaning  of  a 
message  in  non-language  symbols  is  determined  by 
special  reference  rules.  For  example,  *  ■*  *  in  one 
context  may  stand  for  1  turn  right*;  in  another 
context,  fyou  are  too  far  to  the  right.*  A  red 
light  or  a  high-pitched  tone  may  stand  for 
1  danger, *  ’stop,  1  or  any  statement  it  is  refer¬ 
enced  to.  Non-language  symbols  have  no  necessary 
correspondence  to  their  referents,  but  the  form 
of  the  symbols  may  simplify  interpretation:  a 

symbol  that  stands  for  *  aircraft*  may  be  a  circle 
or  a  line  drawing  of  an  aircraft.  The  drawing 
conveys  the  message  ’’aircraft”  directly;  the 
circle  requires  an  intermediate  process,  ’circle’ 
stands  for  ’aircraft.*  Non- 1 anguage-symbo 1  dis¬ 
play  messages  may  be  communications  from  man  to 
man  or  from  machine  to  man. 


c,  A  signal  pattern.  The  meaning  of  a  signal  pattern 
also  is  determined  by  special  reference  rules,  but 
a  given  pattern  may  have  a  close  correspondence  to 
characteristics  of  its  referent.  For  example,  a 
signal  pattern  displayed  on  a  sonar  PPI  scope  may 
signify,  in  addition  to  the  presence  and  location 
of  a  target,  the  nature  of  the  target--that  it  is 

a  submarine  of  a  given  size  and  aspect.  The  char¬ 
acteristics  of  signal  patterns  may  bear  a  one-to-one 
relationship  to  certain  characteristics  of  refer¬ 
ents.  The  re lat ionships  between  signal-pattern 
and  referent  characteristics  are  not  always  known, 
but  the  potential  exists  to  establish  the  relation¬ 
ship  where  the  displayed  signal  pattern  is  a 
transformed  form  of  the  energy  pattern  sensed  from 
the  referent.  The  essential  difference  between  a 
non-language  symbol  pattern  and  a  signal  pattern 
lies  in  their  referent  re lationships .  In  the 
first,  the  relations h ip  is  arbitrarily  defined: 

*X*  stands  for  *Y*;  in  the  second,  the  relation¬ 
ship  also  is  defined  but  may  be  functionally 
specified:  X  =  f(Y).  Signal-pattern  messages  are 

communications  from  machine  to  man. 

d.  A  control  pattern.  The  meaning  of  a  control-pattern 
message  is  determined  by  rules  of  correspondence 
between  control  activation  and  consequence.  For 
example,  pushing  a  button  labeled  ”SEQ,J  results  in 
removal  of  a  present  message  and  presentation  of  a 
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new  message  on  a  display.  Movements  of  a  control 
lever  may  result  in  corresponding  movements  of  a 
symbol  on  a  display  or  movements  of  a  vehicle.  A 
con t ro 1 -p at t e rn  message  may  be  a  single  button  push, 
repetitive  pushes  of  a  single  button,  a  sequence  or 
pattern  of  button  pushes,  or  discrete  or  continuous 
movement  of  a  variable  control.  Control-pattern 
messages  are  communications  from  man  to  machine; 
the  machine  may  change  its  functioning  or  that  of 
another  machine  in  response  to  the  message,  or  it 
may  process  the  message  and  display  it  or  some 
other  message  to  a  man. 

(C)  Messages  may  be  in  other  formats:  hand  signals,  facial 
expressions,  direct  sense  impressions  of  the  environment,  all 
may  be  messages  in  the  sense  that  they  activate  some  response. 

But  the  four  message  formats  described  ab ove - -  1  an guage  symbol, 
non-language  symbol,  signal,  and  control  p at t e rns - - are  the 
relevant  ones  for  command- and- control ,  man-machine  systems. 

These  are  the  formats  the  system  engineers  must  consider  in 
the  design  of  an  information-processing  system,  and  in  the 
allocation  of  functions  to  men  or  to  machines.  A  case  could 
be  made  that  the  basic  analysis  of  a  man-machine  system  is 
done  in  terms  of  the  message  requirements  of  the  system.  What 
are  the  necessary  messages?  What  messages  should  be  processed 
by  men,  by  machines?  What  are  the  message  format  and  display 
requirements  for  machine - 1 o- man  communications?  What  are  the 
control  message  requirements  for  man- t o- machine  communications? 
Questions  like  these  are  posed  and  answered  implicitly  or 
explicitly  in  the  design  evolution  of  any  man-machine  system. 

For  example,  in  the  NTDS  system,  the  designers  doubtlessly 
considered  the  question,  "How  should  the  target  be  displayed 
to  the  DET/TRK?"  Their  decision  was  to  display  the  radar  raw 
video  on  the  PP1;  that  is,  the  detection  task  was  assigned  to 
man,  and  the  message  format  was  a  signal  pattern.  Their 
reasons  for  the  decision  were  probably  based  on  the  fact  that 
man  is  a  better  detector  than  machine  in  this  situation.  But 
the  DET/TRK  also  makes  other  than  a  detection  response  to  the 
video  or  signal-pattern  message.  He  locates  the  initial  position 
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of  the  target  represented  by  the  signal  pattern  and  keeps 
track  of  its  position  on  successive  presentations  of  the  pat¬ 
tern.  He  does  this  by  aligning  a  small  circular  symbol  with 
the  "center  leading  edge  of  the  video"  and  then  pushing  an 
appropriate  button  tc  enter  the  position.  It  could  be  that 
once  a  target  is  detected  and  entered  into  the  system  the 
s i gn a  1 -p at te rn  message  format  has  served  its  purpose;  for 
the  subsequent  location  responses,  perhaps  the  machine  could 
solve  for  the  "center"  and  present  a  non-language  symbol 
representing  it  that  would  make  the  operator's  alignment 
task  easier  and  more  accurate.  The  point  of  this  discourse 
is  not  that  the  message  format  is  necessarily  inappropriate 
for  the  tracking  task --we  don't  know  if  it  is  or  not--but 
that  the  selection  of  format  obviously  depends  on  the  kind 
of  information  conveyed  by  the  message  and  the  nature  of  the 
response  to  it. 


(U)  The  content  of  a  message  may  be  data  ("this  is  a  hostile 
target")  or  instruction  ("destroy  the  target")  or  both  ("this 
is  a  hostile  target;  destroy  it").  Actually,  all  relevant 
system  messages  imply  "instructions";  that  is,  they  must 
result  in  response  decisions  or  actions.  Indeed,  an  opera¬ 
tional  definition  of  the  "meaning"  of  a  message  would  be  in 
terms  of  the  response  to  it.  A  data  message  such  as  "hostile 
target"  not  only  indicates  the  presence  of  a  target  but  gen¬ 
erates  a  series  of  decisions  and  actions:  "it  is  a  threat 

to  us  or  it  is  not,"  "determine  the  characteristics  of  the 
target,"  "keep  track  of  it,"  "destroy  it,"  and  so  on.  It  is 
evident  that  the  "total"  meaning  of  a  message  depends  on  the 
context  in  which  it  occurs. 


(U)  The  definition  of  "message"  includes  the  phrase  "results 
in  a  useful  system  response."  The  intent  here  is  to  dis¬ 
tinguish  between  messages  and  non-messages  in  a  given  system. 
Non-messages  may  be  perceived  as  messages,  such  as  interpret¬ 
ing  a  signal  pattern  as  a  target  of  interest  when  in  fact  it 
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is  not.  If  a  non-message  is  responded  to  as  if  it  were  a 
message,  the  result  may  be  responses  that  are  not  only  not 
"useful"  to  the  system  but  that  degrade  system  performance. 
If  system  non-messages  are  perceived  as  such,  the  responses 
to  them  would  be  useful  system  responses.  Perhaps  the  non¬ 
message  concept  is  not  really  necessary  (a  s i gn al -p at t ern 
message  could  signify  "noise")  but  it  seems  convenient  in 
analyzing  the  significance  of  events  in  a  given  system. 
Again,  the  context  would  determine  whether  an  event  was  a 
message  or  non-message. 


(U)  There  are  literally  thousands  of  messages  in  a  complex 
system  like  the  NTDS.  Some  examples  by  message  format  follow. 

(C)  Language  symbol  messages .  Radio  voice  communications 
are  an  integral  part  of  the  system.  The  TRK  SUP  may  tell  the 
DET/TRK  "check  the  area  indicated  by  the  pointer  for  a  tar¬ 
get,"  "update  your  trouble  tracks,"  or  "your  tracking  per¬ 
formance  is  lousy."  The  IC  may  tell  an  interceptor  pilot 
the  course,  speed,  and  altitude  he  is  to  fly  to  intercept  a 
hostile  aircraft.  The  FWC  may  ask  for  a  CID  report  from  the 
TRK  SUP;  the  TRK  SUP  responds  by  voice.  Language  symbol 
messages  also  are  displayed  on  operator  consoles  such  as  on 
DRO  and  Alert  panels,  and  may  signify  characteristics  of 
a  target  or  instructions  of  what  to  attend  to  next.  Control 
identifications  are  generally  in  language-symbol  format. 

(C)  Non-language  symbol  messages .  There  are  many  non-language 
symbol  messages:  symbols  that  identify  tracks  ( '  /.\  1  for 
'air  hostile'),  that  indicate  some  action  taken  ( '  /\  '  for 
'air  hostile  engaged  by  interceptor'),  that  indicate  some 
action  to  be  taken  (a  flashing  symbol  for  'trouble  track'), 
that  locate  a  t'rack  ('©',  the  Ball  Tab  symbol)  ,  or  that 
designate  an  area  of  interest  ( ' 1 • I ' .  the  Pointer  symbol). 

Other  non-language  symbols  include  light  and  sound  identifica¬ 
tion  or  warning  messages. 
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(C)  Signal-pattern  messages.  The  message  that  initiates  the 
purposive  behavior  of  the  system  is  a  s i gn a  1 -p at t ern  message, 
the  radar  raw  video  displayed  on  the  PPI.  Other  s i gn al -p att e rn 
messages  are  presented  on  ECM  and  IFF  displays,  primarily  for 
clarification  and  amplification  of  the  basic  message.  But 
the  significant  signal-pattern  message  in  the  NTDS  is  the 
video  corresponding  to  the  targets  sensed  by  radar. 


(C)  Control-pattern  messages .  There  are  also  a  great  many 
control-pattern  messages:  control  actions  that  indicate  a 

target  has  been  detected  and  located  (Ball  Tab  and  Enter  New 
Track  actions),  that  keep  track  of  targets  (Ball  Tab  and 
Position  Correction  actions),  that  request  additional  informa¬ 
tion  (Function  Code  actions),  that  instruct  another  operator 
(Engage  Target  action),  that  inform  another  operator  (Engaged 
Target  action),  that  test  decisions  (Intercept-Trial  geometry 
action),  and  that  affect  message  clarity  (PPI  display  adjust¬ 
ment  actions).  Most  NTDS  messages  are  initiated  by  activation 
of  console  controls. 


2.  Display /Receive 

(U)  Definition.  ' Di sp 1  ay /re cei ve '  stands  for  'presenting 

messages  in  a  format  for  human  reception.' 

(U)  Comment.  This  term  and  all  subsequent  ones  are  defined 
as  processes.  Messages,  of  course,  are  the  basic  units  that 
are  processed.  We  have  added  'receive'  to  Miller's  term  to 
emphasize  that  both  a  process  and  a  human  receiver  are 
referenced.  An  analysis  of  performance  in  a  given  situation 
must  take  into  account  the  characteristics  of  the  displaying 
equipment  and  message  format. 

3.  Control /Transmit 

(U)  Definition.  ' Control/transmit'  stands  for  'initiating 
the  transfer  of  a  message  from  one  place  to  another. ' 

(C)  Comment.  We  have  combined  two  of  Miller's  terms  to  arrive 
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at  this  term,  perhaps  unwisely.  It  seems  to  us,  though,  that 
it  is  convenient  to  think  of  control  actions  as  initiators 
of  the  transmission  of  a  message.  For  example,  rolling  the 
Track  Ball  sends  a  message  to  the  computer  that  is  processed 
and  results  in  changes  in  the  position  of  the  Ball  Tab.  Our 
engineers  tend  to  feel  that  the  terms  should  be  separate, 
that  'control'  should  mean  something  like  'directing  a 
physical  action.'  But  if  messages  are  the  things  processed, 
then.. .well,  we  shall  reserve  judgment. 

4 .  Input  Select 

(U)  Definition .  'Input  select'  stands  for  'determining  the 
priority  of  a  message  or  message  channel. 

(C)  Comment .  IVe  have  included  Miller's  "queue  to  channel" 
concept  in  the  definition  of  this  term.  The  input  select 
process  may  be  initiated  by  a  message  from  the  external  en¬ 
vironment,  such  as  a  flashing  symbol  indicating  "trouble 
track";  or  by  an  operator  simply  deciding  what  to  attend  to 
next,  such  as  the  TRK  SUP  evaluating  the  performance  of  a 
DET/TRK . 

5.  Filter /Purge 

(U)  Definition .  'Filter/purge'  stands  for  'eliminating  ir¬ 
relevant  information,  n on- mes s ages ,  or  unwanted  messages. 

(U)  Comment .  Two  of  Miller's  terms  are  combined.  They  seem 
to  us  to  mean  about  the  same  thing,  even  though  'filter'  has 
a  special  meaning  for  engineers.  This  combination  may  violate 
a  principle  earlier  stated  about  established  meaning  of  terms. 

6.  Search/Detect 

(U)  Definition .  'Search/detect'  stands  for  'scanning  a  field 

and  determining  if  a  message  is  present.' 

(U)  Comment .  This  combining  of  terms  makes  a  great  deal  of 
sense  to  us.  Search  usually  involves  a  "search  image"  (Miller 
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pointed  this  out);  that  is,  somebody  is  looking  for  something. 
When  a  message  is  perceived  that  "fits”  the  image,  a  detection 
occurs . 


7 .  Classify /Identify 

(U)  Definition .  1 C 1  as s i fy / i den t i fy 1  stands  for  'assigning 
a  message  to  categories  and  naming  the  message  or  the  cate¬ 
gories  .  1 

(U)  Comment .  We  have  substituted  'classify'  for  Miller's 
'categorize'  and  combined  it  with  his  'identify.'  The  terms 
already  have  rich  connotations,  and  we  feel  that  different 
levels  of  the  same  process  are  involved  in  classification  and 
i dent i f i cat i on . 

8.  Interpret 

(U)  Definition .  'Interpret'  stands  for  'determining  the 
meaning  of  a  message  and  its  significance  to  system  objectives 

(U)  Comment .  A  message  may  be  classified  and  identified  and 
otherwise  processed,  but  its  significance  must  be  assessed 
before  effective  action  can  be  taken. 


9.  Code/Edit 

(U)  Definition .  'Code/edit'  stands  for  'changing  a  message 
from  one  format  to  another  and  selecting  a  suitable  format.' 

(U)  Comment .  Perhaps  the  two  concepts  of  Miller  should  not 
be  combined,  but  changing  a  message  format  seems  to  us  to 
always  involve  an  editing  process.  The  process  refers  to 
both  encoding  and  decoding  actions. 

10.  Long-Term  Store 

(U)  Definition .  'Long-term  store*  stands  for  'holding  some¬ 
thing  in  memory  from  one  system  evolution  to  another.' 

(U)  Comment.  'Evolution'  refers  to  the  series  of  actions 
that  take  place  within  a  given  time  span  of  system  performance 
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Examples  of  long-term  store  are  the  operator  procedures  and 
the  computer  processing  programs  that  are  common  from  one 
evolution  to  another.  For  contrast,  see  the  next  term. 


11.  Short-Term  Store 


(U)  Definition .  ’ Short-term  store'  stands  for  'holding 

something  in  memory  within  the  time-span  of  a  system  evolu¬ 
tion.  1 


(U)  Comment .  Examples  of  short-term  store  are  the  identifica¬ 
tions  of  targets,  the  status  of  friendly  aircraft,  or  the 
location  of  hostile  aircraft;  in  short,  most  messages  that 
are  processed  in  one  system  evolution  are  held  in  short-term 
memory  for  varying  periods  of  time  but  are  not  carried  over 
to  the  next  evolution  (what  is  teamed  from  the  processing 
activity  may  be  "transferred"  to  long-term  memory). 

12.  Plan 

(U)  Definition .  'Plan'  stands  for  'anticipating  conditions, 
considering  options  available,  and  assigning  probable  re¬ 
sponses  .  ' 

(U)  Comment .  Effective  use  of  the  planning  process  can  have 
a  significant  effect  on  the  quality  of  subsequent  performance 
and  on  response  times  to  new  messages,  particularly  in 
decision-making  activities. 

13.  Interrogate 

(U)  Definition .  'Interrogate*  stands  for  'seeking  informa¬ 
tion  that  is  not  presently  displayed,' 

00  Comment .  Miller  did  not  use  this  term  and  did  not  seem 
to  have  a  correlative  one  in  his  taxonomy.  It  seems  important 
to  distinguish  this  process,  particularly  in  computerized 
systems  where  much  information  is  held  in  long-  or  short-term 
store.  Of  course,  humans  are  interrogated,  as  well. 


55 


THIS  PAGE  UNCLASSIFIED 


14.  Analyze /Compute 

(U)  Definition.  ' Analyze/compute '  stands  for  'determining 
the  relationships  among  messages  or  elements  of  a  message.' 

(U)  Comment.  IVe  have  added  'analyze'  to  Miller's  'compute' 
to  take  advantage  of  the  connotations  of  the  term  and  to 
broaden  the  concept  a  bit.  'Compute'  generally  refers  to  a 
mathematical  process;  the  expanded  term  includes  other  logi¬ 
cal,  n on-math emat i ca 1 ,  processes. 

15.  Test/Compare 

(U)  Definition.  ' Tes t / compare '  stands  for  'determining 

whether  a  message  or  a  response  is  valid  or  appropriate.' 

(C)  Comment.  We  have  added  'compare'  to  Miller's  term  to 
include  an  important  element  of  the  testing  process.  We 
think  of  the  test/compare  process  as  applying  to  testing  a 
specific  hypothesis.  For  example,  the  process  is  involved 
when  the  DET/TRK  compares  the  position  of  the  Ball  Tab  to 
the  estimated  position  of  the  "center  leading  edge"  of  the 
video  and  decides  whether  the  positions  correspond.  The 
process  is  also  involved  when  the  IC  calls  for  (interrogates) 
trial  geometry  to  determine  if  an  intercept-target  assign¬ 
ment  will  likely  result  in  an  interception. 


16. 

Es timate 

(U) 

Definition 

.  'Estimate'  stands 

for  'assigning  a 

va  lue 

t  o 

an  event  or 

to  the 

occurrence  of 

an  event . 1 

(C) 

Comment . 

Miller 

did  not  include  this  term,  but 

it 

seems  important  in  an  information-processing  system.  For 
example,  the  IC  estimates  the  change  in  the  time  and  loca¬ 
tion  of  an  interception  that  would  result  if  lie  ordered  a 
change  in  speed  of  the  interceptor.  He  also  may  estimate 
the  weapon  release  point  (time)  of  a  hostile  aircraft  to 
determine  if  a  timely  Interception  will  occur. 
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17.  Evaluate 


(U)  Definition.  'Evaluate'  stands  for  'determining  the 
status  of  a  situation  and  its  value  to  system  objectives.' 

(C)  Comment.  Miller  did  not  have  this  term,  but  it  may  be 
implied  by  other  terms  in  his  taxonomy.  Evaluation  may  in¬ 
clude  testing  and  comparing,  but  the  level  of  hypotheses 
testing  is  much  "higher"  and  applies  to  broader  objectives, 
rather  than  to  narrow  specific  objectives  as  does  the  test/ 
compare  process.  For  example,  the  FWC  evaluates  the  tactical 
situation  in  considering  how  to  deploy  forces.  lie  may  also 
evaluate  the  threat  to  his  forces  of  hostile  forces.  The 
evaluate  process  is  an  integral  part  of  the  decision-making 
activities  in  command- and- control  systems. 

18.  Decide/Select 

(U)  Definition .  1 De ci de/se le ct *  stands  for  'considering 

alternatives  and  determining  an  appropriate  course  of  action.' 

(C)  Comment ,  The  decide/select  process  is  perhaps  the  most 
significant  process  in  command- and- contro 1  system  task  per¬ 
formance.  It  is  present  at  all  levels  of  system  performance: 
from  the  DET/TRK,  who  decides  what  track  to  attend  to  next, 
to  the  FWC,  who  decides  upon  the  deployment  of  his  forces. 

And  it  is  also  the  process  that  is  most  difficult  to  study 
to  determine  what  is  going  on  between  overt  response  events. 

Error  Classifi cation 

(U)  The  error  classification  scheme  that  is  appropriate  is 
largely  implied  by  the  taxonomy.  Thus,  we  may  identify  an 
interpret  error,  a  c on t r o  1  / 1 r ans mi t  error,  a  di sp 1  ay / re ce i ve 
error,  and  so  on.  This  has  the  advantage  of  relating  the 
error  to  the  process  ongoing  at  the  time  it  occurs.  But  it 
is  also  necessary  to  identify  the  type  of  error  that  occurs 
to  better  understand  the  reasons  for  the  occurrence  of  the 
error.  Therefore,  we  propose  a  two-level  error  classification 
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scheme;  one  level  based  on  taxonomy  terms,  and  the  other  on 
the  type  of  error,  as  described  below. 


(U)  Omission  error.  Failure  to  make  a  required  response, 
or  to  receive  a  message. 

(U)  Commission  error.  Making  an  inaccurate  response  to  a 
received  message. 


(U)  Substitution  error.  Making  the  wrong  response  to  a 
message. 


(U)  Sequence  error.  Making  a  response  out  of  order. 

(U)  Time  error.  Failure  to  make  a  response  in  a  given  time 
period,  or  at  a  timely  point. 
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CHARACTERISTICS  OF  AN  OPERATIONAL  DATA  BANK 


(U)  The  main  purpose  of  this  study  was  to  determine  the 
characteristics  of  an  operational  data  bank  for  command-and- 
control  systems.  We  have  identified  some  minimal  character¬ 
istics  required  if  the  operational  data  bank  is  to  be  useful. 
These  characteristics  are  described,  by  example,  on  the  fol¬ 
lowing  pages.  Some  assumptions  have  been  made  in  selecting 
the  content  and  format  of  the  data  bank. 

(U)  First,  we  have  assumed  that  the  primary  user  of  the  data 
bank  will  be  the  system  designer,  though  not  necessarily  the 
exclusive  user.  The  format  of  the  data  bank,  then,  must  be 
in  terms  the  engineer  understands  and  the  data  in  a  form  he 
can  use.  The  data  bank  should  also  be  available  and  provide 
useful  information  to  other  users.  The  manager  of  an  exist¬ 
ing  system  should  be  able  to  refer  to  the  bank  for  performance 
standards  ,  obtained  under  different  operating  conditions,  to 
evaluate  his  operation  of  the  system.  The  person  charged  with 
manning  a  system  should  be  able  to  refer  to  the  bank  to  select 
operators  on  variables  related  to  effective  performance.  The 
person  charged  with  training  should  be  able  to  refer  to  the 
bank  to  determine  training  requirements  and  performance  criteria. 

(U)  Second,  we  have  assumed  a  level  of  description  of  task 
performance.  It  is  a  relatively  molar  level,  largely  deter¬ 
mined  by  the  terms  of  the  preliminary  taxonomy  of  human  per¬ 
formance  described  earlier.  However,  if  information  is 
available  about  intermediate  levels  of  performance,  it  should 
be  included  in  the  bank.  In  the  example  task,  described  below, 
we  have  identified  the  response  sequence  as  well  as  the  major 
task  events . 

(U)  Third,  and  very  important,  we  have  assumed  the  existence 
of  a  data  bank  compiler ,  someone  who  interprets  the  signifi¬ 
cance  of  operational  data  and  translates  it  into  terms  the 
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user  can  understand.  Although  this  is  an  operational  data 
bank,  the  compiler  would  refer  to  other  sources,  including 
laboratory  research  literature,  in  making  his  interpreta¬ 
tions.  The  engineer,  generally,  must  make  his  design  deci¬ 
sions  now ;  the  bank  should  provide  him  with  all  relevant 
data,  even  though  extensive  operational  data  may  not  be  pres¬ 
ently  avai 1 ab le  , 

(U)  We  have  shown  in  Table  2,  on  the  pages  following  this 
discussion,  an  example  of  what  a  data  bank  readout  might 
look  like.  We  have  assumed  what  we  call  a  Detect  and  Locate 
task,  and  we  use  an  actual  task  from  the  NTDS  for  illustra¬ 
tion.  However,  all  of  the  data  are  hypothetical.  The  main 
sections  of  the  data  bank  readout  are  discussed  below. 


(U)  System  and  Equipment .  The  machine  involved  in  the  per¬ 
formance  of  a  man-machine  task  must,  of  course,  be  thoroughly 
described.  Whether  the  machine  description  be  incorporated 
in  the  data  bank  or  whether  the  data  bank  references  another 
source  for  the  description  probably  depends  on  the  extensive¬ 
ness  of  the  machine  documentation  and  its  availability  to  the 
data  bank  user.  In  the  case  of  the  NTDS  example  task,  we 
have  identified  the  relevant  equipment  and  referenced  the 
source  documents. 


(U)  Task  Description .  The  sequence  of  performance  events  in 
the  task  must  be  described  in  detail,  and  the  significant  task 
events  must  be  identified  and  associated  with  the  respective 
performance  events.  We  believe  that  the  performance  data  in 
the  bank  should  apply  to  task  events,  that  those  data  will 
prove  most  useful  to  the  design  engineer.  In  the  example, 
the  task  events  are  detect >  locate >  and  task  complete .  The 
response  sequence  associated  with  the  task  events  is  identified 
also.  The  messages  processed  during  the  performance  of  the 
task  are  identified.  The  format  of  the  messages  will  be  best 
appreciated  by  careful  study  of  the  display  and  control 
features  of  the  relevant  equipment. 
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(U)  Performance  Measures.  The  relevant  dependent  variables 
must  be  identified  and  operationally  defined.  What  variables 
are  relevant  will  depend  on  the  particular  task  and  on  the 
task  events  identified.  In  the  example,  the  dependent  vari¬ 
ables  are  detection  time,  location  time,  task  completion  time, 
false  alarm  frequency,  and  location  accuracy.  The  performance 
measures  derived  from  these  variables  are  probability  of  cor¬ 
rect  response  by  time  (for  detect ,  locate ,  and  task  complete 
events),  false  alarm  rate,  and  the  mean  and  standard  deviation 
(or  other  appropriate  summary  statistics)  of  location  error. 

(U)  We  believe  that  the  most  significant  dependent  measure  to 
observe  in  command- and- control  systems  tasks  is  the  probability 
of  correct  response  by  time.  Figure  3  shows  a  hypothetical 
function  for  the  detect  event  of  the  example  Detect  and  Locate 
task  . 


PROBABILITY 

OF 

DETECTION 


TIME  (IN  SECONDS) 

Figure  3.  Probability  of  detection  (correct  response) 
x  ti me  (in  seconds ) . 


(U)  The  probability  of  correct  response  is  defined  as  the 
ratio  of  correct  detections  to  the  total  number  of  opportu¬ 
nities  to  detect.  The  function  may  represent  the  detection 
performance  of  an  individual  or  that  of  a  group  of  individuals. 
The  design  engineer  is  most  interested  in  group  performance. 
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given  the  characteristics  of  the  group  and  the  conditions  of 
performance  (see  below).  In  the  illustration,  the  opportu¬ 
nity  to  detect  occurred  when  a  s i gnal -p at te rn  message  was 
first  displayed  (at  zero  time):  25%  of  the  task  performers 
detected  the  message  by  30  seconds;  50%  by  64  seconds;  and 
99%  by  326  seconds. 

(U)  The  major  criterion  of  command- and- cont ro 1  system  effec¬ 
tiveness  is  the  response  time  required  for  effective  action. 

If  the  design  engineer  has  available  such  p rob ab i 1 i ty-by- time 
functions,  based  on  operational  data,  for  the  several  command- 
and-control  tasks  and  task  events,  he  may  be  able  both  to 
evaluate  and  to  simulate  alternative  system  configurations. 

Performance  Data 

(U)  The  format  the  data  is  presented  in  depends  on  the  per¬ 
formance  measure.  Whenever  time  to  respond  is  a  significant 
variable,  the  format  is  probability  of  correct  response  as  a 
function  of  time.  In  the  example,  the  major  data  follow  that 
format;  but  they  are  presented  in  tabular  rather  than  graphic 
form,  as  shown  below  for  the  detect  task  event  data  (the 
table  entries  are  times  in  seconds). 


Task  Event 

Probability  of  Correct  Response 

.25 

.50 

.75 

.99 

Detect 

30 

64 

126 

326 

(U)  The  performance  data  are  presented  at  several  levels: 
overall  compilations  for  each  dependent  measure  and  breakdowns 
by  significant  independent  variables  when  the  variables  are 
identified  and  reliable  data  is  available  (in  each  case,  the 
number  of  observations  on  which  the  data  are  based  is  indi¬ 
cated).  The  significant  independent  variables  will  be  "per¬ 
formance  shaping  factors";  that  is,  variables  that  make  a 


•  •  •  •  •  •  • 


62 

>  •  •  • 


THIS  PAGE  UNCLASSIFIED 


<S0JiF$efet*4AL 


THIS  PAGE  UNCLASSIFIED  . . 

. .  *;•  I 


•  •  • 

•  •  •  •  • 

•  •  ••  • 

•  •  •  • 


•  • •  •••  • 


•  •  •  •  • 

•  •  •  •  # 

•  •  • •  ••  „ 

••••  •  ... 

•  •  •••  ••• 


•  ••  • 

•  • 

•  •  •  • 


•  •  •  •  •  * 

•  •  •  < 

•  ••  ••••  •  •  • 


difference  in  performance.  In  the  example,  we  have  included 
a  few  such  variables  likely  to  have  an  important  effect  on 
performance  of  a  detect  and  locate  task:  operator  experi¬ 
ence,  operator  time  on  station  (at  the  task),  number  of 
system  tracks  (competing  messages,  task  load),  and  range  of 
target  (some  significant  variables  will  vary  by  task).  Hy¬ 
pothetical  data  are  presented  for  selected  task  events  by 
the  significant  variables. 


(U)  In  the  example,  false  alarms  are  given  as  a  ratio,  num¬ 
ber  of  false  alarms  to  total  number  of  targets  detected  and 
located.  Location  errors  are  transformed  into  discrepancies 
in  miles  between  true  and  computed  target  position. 

Summary 

(U)  This  is  the  province  of  the  compiler.  The  general  con¬ 
ditions  of  the  operational  data  collection  are  identified 
(e.g.,  fleet  exercises  over  several  days),  the  data  are 
interpreted,  and  other  relevant  data  sources  are  referenced. 
The  example  summary  makes  sense,  in  terms  of  the  hypothetical 
performance  data  and  what  is  known  about  this  kind  of  task. 
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TABLE  2 


HYPOTHETICAL  EXAMPLE  OF  DATA  BANK  READOUT 
DETECT  AND  LOCATE  TASK 


A.  System  and  Equipment 

1.  Naval  Tactical  Data  System 

a.  UYA-4  Console 
•  b.  AN/SPS-48  Radar 

2.  Reference:  Program  Operation  for  Model  III,  Phase  I, 

PD-6072  ( V o 1 .  II  and  III) 


B .  Task  Description 


1.  Initiating  message:  signal  pattern,  raw  radar  video 

2.  Response  messages:  control  pattern  actions 


3.  Task  sequence: 


Task  Event 


a . 

Detect  . 

.  (1) 
(2) 
(3) 

b. 

Locate  . 

•  (4) 

(5) 

(6) 

c . 

Task  Complete.  . 

.  (7) 

Response  Sequence 

Enable  Ball  Tab 
Position  Ball  Tab 
Push  Hook  QAB 
Enter  New  Track 
Position  Correction  QAB* 
Position  Correction  QAB 
Position  Correction  QAB 


4.  Confirmation  messages:  non-language  symbol  patterns 


a.  Tentative  Track  symbol;  after  (4) 

Enter  New  Track;  remains  through  (6) 

b.  Firm  Track  symbol;  after  (7) 

*Note:  If  Position  Correction  QAB  not  activated  in  72 

seconds  after  Enter  New  Track,  the  system  auto¬ 
matically  drops  this  track.  Similarly,  if  the 
elapsed  time  between  Responses  5,  6,  and  7  ex¬ 
ceeds  72  seconds,  the  track  will  be  dropped 
automati cal ly. 


C.  Performance  Me as u res 

1.  Detection  time:  time  between  signal  pattern  entry 
and  Enable  Ball  Tab 
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2.  Location  time:  time  between  signal  pattern  entry  and 

Enter  New  Track 

3.  Task  completion  time:  time  between  signal  pattern 

entry  and  third  position  correction  QAB 

4.  False  alarm  frequency:  number  of  times  track  dropped 


5.  Location  accuracy:  estimated  discrepancy  between  Ball 
Tab  position  and  center  leading  edge  of  signal 
pattern  transformed  to  miles  between  true  and 
computed  target  position 


D.  Performance  Data 

1.  Probability  of  correct  response  by  time  in  seconds 
(N  =  100) 

a .  Overal 1 


Probability  of  Correct  Response 

Task  Event 

.25 

.50 

.75 

.99 

Detect 

30 

64 

126 

326 

Locate 

36 

71 

131 

332 

Task 

Comp! ete 

191 

221 

309 

485 

b.  By  Operator  Experience  (for  Detect  task  event  only) 


Probability  of  Correct 
Response 

Experience  Level 

.25 

.  50 

.75 

.99 

N 

<  3  mos . 

52 

140 

245 

492 

21 

3-6  mos  .  . 

38 

61 

115 

319 

28 

>  6  mos. 

25 

51 

106 

228 

51 
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TABLE  2 
( Con  ti nued) 


Performance  Data  (continued) 

c.  By  Operator  Time  on  Station  (for  Locate  task 
event:  Time  to  Position  Ball  Tab  only) 


Probability  of  Correct 
Response 

Time  on 

Station 

.25 

.50 

.  75 

.99 

N 

0-30  min. 

3 

4 

4.5 

5 

23 

31-60  min. 

3.5 

5 

6 

8 

24 

60-240  mi n . 

5 

7 

8 

8.5 

42 

240+  min. 

8 

10 

10.5 

12 

1 1 

d.  By  Number  of  System  Tracks  (for  Task  Complete 
event  only) 


Probability  of  Correct 
Response 

Number  of  Tracks 

.25 

.50 

.  75 

.99 

N 

1-3 

163 

208 

274 

342 

28 

4-6 

158 

204 

286 

405 

35 

7-10 

208 

216 

333 

582 

24 

11  or  more 

234 

265 

384 

609 

13 
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Performance  Data  (continued ) 

e.  By  Range  of  Target  (for  Locate  task  event  only) 


Probability  of  Correct 
Response 

Range 

.25 

.50 

.75 

.99 

N 

0-60  miles 

20 

31 

39 

52 

23 

60-140  miles 

23 

58 

142 

201 

23 

140-210  miles 

38 

93 

1  78 

305 

41 

more  than  210 

47 

138 

233 

408 

13 

2.  False  Alarm  Rate 


a.  Overall 

5/100  =  .05  rate 

Note:  Data  base  not  adequate  for  additional  breaks 

3.  Location  Accuracy  Error  in  Transformed  Miles 

a .  Overall 

Mean  Error  =  3.0  miles 
SD  =  1.25  mi  1 es 
N  =  100 

b.  By  Range  of  Target 


Range 

Mean  Error 

SD 

N 

0-60  miles 

3.1 

1.10 

23 

60-140  miles 

1  .  8 

0.61 

23 

140-210  miles 

2.8 

0.92 

41 

>  210  miles 

5.8 

2.15 

13 
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c.  By  Number  of  System  Tracks 


No .  of 
Tracks 

Mean 

Error 

SD 

N 

1-3 

2.7 

0.88 

28 

4-6 

2.1 

0.71 

35 

7-10 

3.6 

1.13 

24 

>  11 

5.1 

2.18 

13 

E .  Summary 

Compare  Detect  and  Locate  performance  for  operators  using 
the  AN/SPS-48  and  the  AN/SPS-40  Radar.  Use  search  terms  Detect 
and  Locate  tasks,  NTDS ,  UYA-4,  and  AN/SPS-40  Radar.  The 
AN-SPS-48  produces  both  a  reduced  rate  of  false  alarms  and 
greater  location  accuracy.  The  data  indicate  that  the  optimum 
elapsed  time  between  updates  is  50-65  seconds;  when  either 
more  or  less  than  50-65  seconds  elapse  between  updates,  track¬ 
ing  tends  to  be  less  accurate;  when  1-6  system  tracks  are 
present,  updates  tend  to  occur  during  the  optimum  time;  when 
the  number  of  tracks  increases,  updating  behavior  becomes 
random  and  frequently  occurs  both  sooner  and  later  than  the 
optimum  time. 

Note  that  for  the  break  by  number  of  system  tracks,  D.l.d., 
performance  is  better  when  4-6  system  tracks  are  present  than 
when  only  1-3  tracks  are  present.  In  addition,  a  very  signifi¬ 
cant  time  differential  can  be  noted  between  the  .50  and  .75 
levels  of  probability  of  correct  response  when  7-10  system 
tracks  are  present. 

Note  that  initial  location  accuracy  for  close  in,  0-60 
miles,  is  not  as  good  as  for  targets  between  60  and  210  miles. 
The  apparent  cause  of  this  differential  is  a  lack  of  delibera¬ 
tion  by  the  operator  in  entering  Late  Detect  targets. 
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(U)  We  have  taken  some  steps  towards  developing  a  taxonomy 
of  human  performance,  the  characteristics  of  an  operational 
data  bank,  and  methods  of  collecting  operational  data.  But 
we  have  barely  scratched  the  surface  of  what  needs  to  be  done. 
We  recommend  that  continued  research  be  focused  on  these 
ar e as - - p e r f o rman ce  taxonomy,  operational  data  bank,  data  col¬ 
lection  methods--and  that  the  NTDS  continue  to  be  the  command- 
and-control  system  under  study. 

Taxonomy  of  Human  Performance 

(U)  Further  research  on  the  taxonomy  should  be  directed 
toward  whether  or  not  it  meets  two  major  purposes:  communica¬ 

tion  with  systems  engineers  and  a  useful  level  of  task  de¬ 
scription.  To  determine  if  the  taxonomy  meets  the  first 
purpose,  engineers  and  system  designers  have  to  be  exposed 
to  the  taxonomy.  We  recommend  that  substantial  numbers  of 
engineer/designers  be  interviewed  to  assess  the  strengths  and 
weaknesses  of  the  taxonomy.  The  result  should  be  an  effective 
communication  device.  To  determine  if  the  taxonomy  meets  the 
second  purpose,  more  accurate  descriptions  of  command- and- 
control  tasks  are  needed.  We  believe  that  cur  descriptions  of 
the  NTDS  tasks  are  probably  reasonably  accurate,  but  they  lack 
an  essential  input:  substantial  operational  data.  We  recom¬ 
mend  that  operational  performance  data  be  collected  on  the 
NTDS  (see  below) . 

Characteristics  of  an  Operational  Data  Bank 

(U)  Further  research  on  data  bank  characteristics  should  be 
directed  toward  whether  or  not  the  systems  engineer/designer 
finds  the  bank  useful.  We  recommend,  as  for  the  taxonomy, 
that  substantial  numbers  of  engineer/designers  be  interviewed 
to  determine  just  what  characteristics  are  required  to  make 
the  data  bank  a  useful  tool.  It  would  be  pointless  to  assemble 
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intended  users. 

Data  Collection  Methods 


(U)  The  most  important  requirement  for  further  research  is 
to  continue  the  development  of  data  collection  methods  and 
to  collect  operational  data.  On  the  next  several  pages  is  a 
detailed  plan  for  collecting  operational  data  from  the  NTDS. 
The  plan  is  organized  by  NTDS  tasks.  The  following  specifica¬ 
tions  are  included: 


1.  The  data  required  to  evaluate  task  performance. 

2.  The  data  sources  (the  data  collection  methods) 
and  \shat  data  may  be  obtained  from  them;  the 
methods  are  direct  recording  (the  DRS), 
observer  recording,  and  interview.  "Interview" 
includes  the  judgmental  data  collection  methods. 

3.  The  reduced  data  required  for  the  data  bank  and 
for  task  evaluation. 

(U)  We  recommend  that  the  data  be  collected  aboard  ship 
during  operational  exercises,  so  that  validation  data  may 
also  be  collected. 
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DATA  COLLECTION  PLAN 
Task  1:  Search 

(C)  Data  Required:  The  search  activity  and  strategy  of  the 
NTDS  team. 

1.  Identity  of  consoles  engaged  in  search. 

2.  Mode,  radar,  range  scale,  and  search  sector 
by  console. 

3.  Search  strategy  rationale. 

(C)  Data  Sources:  The  data  required  is  available. 

1.  Data  Recording  System. 

a.  Mode  and  radar  by  console  (A-12  Panel  QAB). 

b.  Size,  shape,  location  of  search  sector 
(Ball  Tab  x-y  position  when  Entry  Offset 
QAB  entered  at  A-ll  panel). 

2.  Observer  Recording. 

a.  Range  scale  by  console. 

b.  Operator  search  behavior. 

3.  Interview. 

a.  Rationale  for  search  assignments  (TRK  SUP). 

b.  Rationale  for  search  procedures  (TRK  SUP). 

c.  Judgments  of  difficulty  of  search  task  (TRK 
SUP  and  DET/TRK) . 

(C)  Reduced  Data  Required 

1.  Tabulation  of  search  mode,  radar,  range  scale, 
and  sector  by  console. 

2.  Scaling  of  search  difficulty  measures. 
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Task  2:  Detect 


(C)  Data  Required:  The  conditions  of  detection. 

1.  Target  type  (signal-pattern  referent). 

2.  Characteristics  of  signal  pattern:  size,  S/N 
ratio . 

3.  Time  of  signal  pattern  display  entry. 

4.  Time  of  detection. 

5.  Range  of  detection. 

6.  Identity  of  detecting  console. 

(C)  Data  Sources:  The  appearance,  location,  or  charac¬ 
teristics  of  raw  video  are  not  directly  fed  into  the 
computer  system;  the  computer  is  informed  of  the 
presence  of  a  signal  pattern  only  when  the  detection 
response  is  made. 

1.  Data  Recording  System. 


a . 

Time  of  detection  (New  Track 
Detect  QAB) . 

or  Late 

b. 

Range  of  detection  (Ball  Tab 
and  New  Track  QAB) . 

x-y  position 

c  . 

Console  detecting. 

2.  Observer  Recording. 

a.  Target  type  and  signal  pattern  characteristics. 

b.  Possibly  time  of  signal  pattern  entry. 

c.  Operator  behavior  and  attentiveness. 

d.  Predicted  detection  range  (from  Fade  Charts). 

e.  False  detections. 

3.  Interview, 
a . 


Detection  criteria  used  (TRK  SUP  and  DET/TRK) . 
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b.  Detection  decision  behavior  (TRK  SUP  and 
DET/TRK) . 

c.  Judgments  of  difficulty  of  detection  task 
(TRK  SUP  and  DET/TRK). 

(C)  Reduced  Data  Required 

1.  Detection  time  (difference  between  signal 
pattern  entry  and  detection). 

2.  Detection  range  (distance  between  own-ship 
or  Vital  Center  and  target). 

3.  Frequency  of  false  detections. 

4.  Scaling  of  decision  behavior  measures  by 
detection  criteria. 

5.  Scaling  of  detection  task  difficulty 
me  asures . 


73 


►  •  •  •  •  • 

>  •  •  • 
•••  ••••  ••• 


•  • 
•  •  •  • 


►  •  •  •  • 

•  •  •  •  •  • 

•  •  •  •  •  • 

•  •  •  •  • 

»  •  •  •  • 


Task  3:  Track  Entry  and  Monitoring 

(C)  Data  Required:  The  conditions  of  track  entry  into 
the  system  and  subsequent  track  corrections. 

].  Time  of  Tentative  Track  entry  (detection). 

2.  Time  of  Tentative  Track  update. 

Time  of  Firm  Track  entry. 

Time  of  Firm  Track  update. 

Time  of  Late  Detect  entry. 

Operator  time  to  enter  or  update  track. 

Total  time  track  is  in  system. 


3 

4 

5 

6 

7 

8 


Distance  traveled  by  target  by  track  update 
events . 


9.  Tracks  dropped  automatically  by  system. 

10.  Tracks  dropped  by  operators. 

11.  Accuracy  of  track  location. 

12.  Occurrence  of  track  confusions. 

13.  Time  of  track  confusion  and  time  of  resolution. 

14.  Identity  of  console. 

(0)  Data  Sources :  Track  accuracy  cannot  be  recorded  directly, 
because  the  position  of  raw  video  is  not  available  to 
the  computer. 

1.  Data  Recording  System. 


a . 

Ti  me 

of 

b  . 

Time 

of 

re  cti on 

c . 

T  i  me 
QAB)  , 

of 

d. 

Time 
QAB)  . 

of 
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e.  Time  of  Late  Detect  entry  (Late  Detect  QAB)  . 

f.  Operator  time  to  enter  or  update  track  (Enable 
Ball  Tab  button  and  New  Track  or  Late  Track 

or  Position  Correction  QAB). 

g.  Total  time  track  is  in  system  (New  Track 
or  Late  Detect  QAB  and  Drop  Track  QAB  or 
automatic  drop  of  track  number). 

h.  Distance  traveled  by  target  (Ball  Tab 
x-y  position  and  QAB  actions). 

i.  Times  of  track  confusions  and  resolutions 
(Nav  check,  Gridlock  Check,  and  Drop  Track 
QAB)  . 

j.  Console  responding. 

2.  Observer  Recording. 

a.  Tracking  accuracy:  direct  observation  of 
DET/TRK  performance. 

b.  Tracking  accuracy:  inferred  from  track 

history  display. 

c.  Operator  entry  and  tracking  behavior. 

3 .  Interview 

a.  Judgments  of  tracking  accuracy  (TRK  SUP 
and  DET/TRK) . 

b.  Judgments  cf  overall  tracking  performance 
(TRK  SUP ,  IC,  and  SWC) . 

c.  Judgments  of  tracking  difficulty  (TRK 
SUP" and  DET/TRK). 

d.  Identification  of  track  confusion  problems 
(TRK  SUP) . 

e.  Reasons  for  dropped  tracks  (TRK  SUP  and 
DET/TRK) . 

(C)  Reduced  Data  Required 

1.  Operator  entry  and  update  times. 

2.  Time  between  Tentative  Track  updates. 
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Time  between  Firm  Track  updates. 

Total  time  track  is  in  system. 

Number  and  rate  of  tracks  per  unit  time. 

Number  of  tracks  dropped  by  reason, 
a.  Tentative  Tracks, 
b  .  Firm  Tracks . 

Number  of  tracks  dropped  and  reentered. 

Number  of  track  confusions. 

Time  to  resolve  track  confusions. 

Scaling  of  tracking  accuracy  measures. 

Scaling  of  overall  tracking  performance  measures. 
Scaling  of  tracking  difficulty  measures. 


Task  4:  Track  Identification 

(C)  Data  Required:  The  identification  performance  of  the 
ID  and  other  operators. 

1.  Target  type  and  characteristics. 

2.  Time  of  Tentative  Track  entry  (detection). 

3.  Time  of  Firm  Track  entry. 

4.  Time  of  ID  Close  Control  action. 

5.  Time  of  identification  response. 

6.  CID  net  reports  by  operator. 

7.  Correctness  of  identification  response. 

8.  Changes  in  identification  response. 

9.  Identification  confirmation  responses. 

10.  Identity  of  console. 

(C)  Data  Sources :  The  ID  responses  that  the  system  acts 
upon  can  be  directly  recorded;  other  events  related 
to  the  identification  process  cannot  be. 

(C)  Data  Recording  System 

1.  Time  of  Tentative  Track  entry  (New  Track  or 
Late  Detect  QAB) . 

2.  Time  of  Firm  Track  entry  (Position  Correction  QAB). 

3.  Time  of  ID  Close  Control  action  (Sequence,  ID, 

or  Hook  symbol  QAB). 

4.  Time  of  identification  response  (ID  QAB). 

5.  Nature  of  identification  response  (ID  QAB). 

6.  Changes  in  identification  response  (ID  QAB). 

7.  Console  responding. 

(C)  Observer  Recording 

1.  Target  type  and  characteristics. 


77 


•  • •  •••• 

•  •  • 

•  •  •  «  • 
•  •  • 

•  •  •  •  •  •  • 


m  #  ••••  « 

:  <%&&&&&■ 

•  • •  • • •••  ###  ###  9  m  *9 


►  •  •  •  •  •  • 


2.  CID  net  communications  (from  Comm  Log). 

3.  Confirmation  responses  (by  TRK  SUP,  SWC,  FWC). 

4.  ID  and  other  operator  roles  and  behavior  in 
the  identification  process. 

(C)  Interview 

1.  Ship's  ID  SOP  and  assigned  roles  of  operators 
(FWC,  SWC,  TRK  SUP,  ID). 

2.  Adequacy  of  ID  source  data  (FWC,  SWC,  TRK 
SUP,  ID). 

3.  Value  of  CID  report  (FWC,  SWC,  TRK  SUP,  ID). 

4.  Identification  decision  criteria  used  (ID,  SWC). 

5.  Identification  decision  behavior  (ID,  SWC). 

6.  Judgments  of  difficulty  of  identification  task 
(ID,  SWC). 

(C)  Reduced  Data  Required 

1.  Time  between  Tentative  Track  and  identification 
responses  (initial  and  final). 

2.  Time  between  Firm  Track  and  identification 
responses  (initial  and  final). 

3.  Correctness  of  identification  response  by 
target  classification  and  category. 

4.  Time  between  track  Close  Control  action  and 
ID  response. 

5.  Time  between  ID  request  for  "outside"  data 
and  response. 

6.  Frequency  of  identification  reviews  by  ID. 

7.  Frequency  of  changes  in  identification  response 
by  initiator  of  change  (e.g.,  FWC  fails  to  con¬ 
firm  ID  response). 

8.  Scaling  of  ID  source  data  measures  of  adequacy 
(confidence  in  identification  response). 
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9.  Scaling  of  identification  behavior  measures 
by  identification  criteria. 

10.  Scaling  of  identification  task  difficulty 
me  as  ure  s . 
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Task  5:  Select  Target  and  Weapon 

(C)  Data  Required.:  The  target  and  weapon  selection  per¬ 
formance  of  FWC ,  SWC,  and  IC. 

1.  Target  type  and  characteristics. 

2.  Time  of  Firm  Track  entry. 

3.  Time  of  ID  response  entry. 

4.  Time  of  track  Close  Control  entry. 

5.  Position  of  target  by  system  events. 

6.  Position  of  weapon  by  system  events. 

7.  Position  of  other  targets  and  weapons  by 
system  events . 

8.  Distance  traveled  by  target  between  events. 

9.  Type  of  weapons  available. 

10.  Intelligence  data  available. 

11.  Target  and  weapon  selection  behavior  by 
operator. 

12.  Consoles  participating. 

(C)  Data  Sources :  The  critical  decision  behaviors  in 
target  and  weapon  selection  cannot  be  directly 
recorded  or  ob s e rve d- - on ly  the  resulting  response. 

1.  Data  Recording  System. 

a.  Time  of  Firm  Track  entry  (Position  Correction 
QAB)  . 

b.  Time  of  ID  entry  (ID  QAB) . 

c.  Time  of  track  Close  Control  entry  (Hook 
and  Track  Review  QABs). 

d.  Time  of  Target  Selection  (Hook  and  Engage 
QABs).  ' 

e.  Time  of  weapon  selection  (Ball  Tab  and 
Engage  QABs ) . 
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f.  Position  of  Target  (Ball  Tab  x-y  position 
and  Position  Correction  QAB) . 

g.  Position  of  weapon  (Position  of  Target  [Ball 
Tab  x-y  position  and  Position  Correction 
QAB]) . 

h.  Positions  of  other  targets  and  weapons  (Posi 
tion  of  Target  [Ball  Tab  x-y  position  and 
Position  Correction  QAB]). 

i.  Distance  traveled  by  target  (Ball  Tab  x-y 
position  and  QAB  actions). 

j.  Identity  of  consoles. 

2.  Observer  Recording. 

a.  Target  type  and  characteristics . 

b.  Weapons  available. 

c.  Intelligence  data  available. 

e.  Operator  overt  behavior  (from  Comm  Log  and 
direct  observation). 

3.  Interview 

a.  Decision  criteria  used  for  target  selec¬ 
tion  (FWC,  SWC). 

b.  Decision  behavior  in  selecting  target 
(FWC,  SWC) . 

c.  Decision  criteria  used  for  weapon  selection 
(FWC,  SWC,  IC). 

d.  Decision  behavior  in  selecting  weapon  (FWC, 
SWC,  IC). 

e.  Decision  behavior  times  for  events  occurring 
between  overt  responses  (FWC,  SWC,  IC). 

f.  Judgments  of  adequacy  of  data  sources  for 
target  and  weapon  selection  (FWC,  SWC,  IC). 

g.  Identification  of  information  required  but 
not  available  (FWC,  SWC,  1C). 

h.  Judgments  of  difficulty  of  the  target  and 
weapon  selection  tasks  (FWC,  SWC,  IC). 
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i.  Judgments  of  performance  of  target  and 
weapon  selection  tasks  by  operator  (FWC, 
SWC,  IC). 


(C)  Reduced  Data  Required 

1.  Times  between  Firm  Track  entry  and  target  and 
weapon  selections. 

2.  Times  between  Close  Control  and  target  and 
weapon  selections . 

3.  Times  between  ID  response  entry  and  targets 
and  weapons  selections. 

4.  Range  of  target  from  own-ship  or  Vital  Area. 

5.  Range  between  target  and  weapon  selected. 

6.  Ranges  of  other  weapons  from  target. 

7.  Frequency  of  changes  in  target  and  weapon 
selections , 

8.  Frequency  of  previous  target  and  weapons 
selections  for  engagement. 

9.  Frequency  of  required  data  unavailability. 

10.  Scaling  of  target  and  weapon  selection  decision 
behavior  measures  by  decision  criteria. 

11.  Scaling  of  target  and  weapon  selection  perfor¬ 
mance  measures  by  operator. 

12.  Scaling  of  target  and  weapon  selection  task 
difficulty  measures  by  operator. 
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Task  6:  Conduct  Engagement 

(C)  Data  Required:  The  performance  of  FWC,  SWC,  IC  and 
other  operators  in  conducting  an  engagement  after 
target  and  weapon  selection. 

1.  Target  type  and  characteristics. 

2.  Weapon  type  and  characteristics. 

3.  Time  of  Firm  Track  entry. 

4.  Time  of  ID  response  entry. 

5.  Times  of  target  and  weapon  selection. 

6.  Positions  of  target  and  weapon. 

7.  Time  of  initiation  of  engagement  entry. 

8.  Time  of  completion  of  engagement. 

9.  Target  weapon  release  point. 

10.  Success  of  engagement. 

11.  Subsequent  weapon  assignment. 

12.  Positions  of  other  targets. 

13.  Conduct  engagement  behavior,  by  operator. 

14.  Consoles  participating. 

(C)  Data  Sources:  Much  of  the  data  required  to  evaluate 
the  conduct  engagement  task  can  be  directly  recorded 
or  observed. 

1.  Data  Recording  System. 

a.  Time  of  Firm  Track  entry  (Position  Correction 
QAB)  . 

b.  Time  of  ID  response  entry  (ID  QAB). 

c.  Times  of. target  and  weapon  selections  (Hook, 
Ball  Tab,  and  Engage  QABs). 

d.  Time  of  Engagement  entry  (Engage  QABs). 
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e.  Time  of  completion  of  engagement  (Cannot 
Comply  QAB  or  weapon  reassign  QAB  actions). 

f.  Positions  of  target  and  weapon  (Ball  Tab 
x-y  position  and  Position  Correction  QAB). 

g.  Positions  of  other  targets  (Positions  of 
target  and  weapon  [Ball  Tab  x-y  position 
and  Position  Correction  QAB]). 

h.  Subsequent  weapon  assignment  (Hook,  Ball 
Tab,  and  Engage  QABs). 

i.  Acceptance  of  engagement  (Cannot  Comply  or 
En  gage  QAB) . 

j.  Identity  of  consoles. 

2.  Observer  Recording 

a.  Target  type  and  characteristics. 

b.  Target  weapon  release  point. 

c.  Weapon  type  and  characteristics. 

d.  Success  of  engagement. 

e.  Operator  overt  behavior  (from  Comm  Log 
and  direct  observation). 

3.  Interview 

a.  Reasons  for  non-acceptance  of  engagements 
(SWC,  IC). 

b.  Decision  criteria  for  conducting  engage¬ 
ments  (FWC,  SWC,  IC). 

c.  Decision  behavior  in  conducting  engage¬ 
ments  (FWC,  SWC,  IC). 

d.  Reasons  for  successful  and  unsuccessful 
engagments  (FWC,  SWC,  IC). 

e.  Judgments  of  performance  in  conducting 
engagements  by  operator  (FWC,  SWC). 

f.  Judgments  of  difficulty  of  the  engagement 
task  (FWC,  SWC,  IC). 
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(C)  Reduced  Data  Required 

1.  Time  between  Firm  Track  entry  and  conduct 
engagement  initiation  and  completion  of 
engagement . 

2.  Time  between  ID  response  entry  and  conduct 
engagement  initiation. 

3.  Time  between  conduct  engagement  initiation 
and  completion  of  engagement. 

4.  Frequency  of  Cannot  Comply  responses  by 
re  as  ons  . 

5.  Frequencies  of  successful  and  unsuccessful 
engagements . 

6.  Ranges  of  target  at  initiation  and  completion 
of  engagements . 

7.  Scaling  of  decision  behavior  measures  by 
decision  criteria. 

8.  Scaling  of  conduct  engagement  performance 
measures  by  operator. 

9.  Scaling  of  conduct  engagement  task  differently 
by  operator. 
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Mis  si  on- Support  Tasks 

(C)  The  six  tasks  discussed  on  the  preceding  pages  can  be 
referred  to  as  "main-thread"  tasks;  that  is,  they  are  tasks 
concerned  with  the  primary  mission  of  the  NTDS  system:  de¬ 

tecting  targets,  identifying  them,  keeping  track  of  them, 
deciding  what  to  do  about  them,  and  taking  some  appropriate 
action.  But  there  are  a  number  of  other  tasks  that  must 
be  accomplished  if  the  primary  mission  is  to  be  successful. 
These  can  be  referred  to  as  "mission-support"  tasks.  Many 
of  these  tasks  are  performed  by  the  TRK  SUP,  probably  the 
operator  who  has  the  heaviest  task  load.  Three  of  the  TRK 
SUP  mi ss i on- support  tasks  are  discussed  below:  Geographic 
Positioning,  Gridlock,  and  Track  Supervision. 

(C)  Data  is  required  to  determine  the  importance  of  these 
mis s ion - s upp or t  tasks,  the  frequency  with  which  they  are 
performed,  the  amount  of  time  required  to  perform  them  and, 
perhaps  most  important,  to  attempt  to  establish  performance 
standards  for  the  tasks  in  terms  of  system  or  mission  require¬ 
ments,  The  common  characteristics  of  these  tasks  are  that 
they  occur  aperiodi cal ly  and  that  they  are,  for  the  most  part, 
operator  initiated;  the  system  does  not  normally  provide  a 
direct  indication  of  when  these  tasks  should  be  performed. 
Another  common  characteristic  of  the  system  support  tasks 
may  be  that  they  are  independent  of  one  another  and  of  the 
mi s s i on  -  re  1  a t ed  activity  level. 

(C)  Mission-Support  Task  1:  Geographic  Positioning .  The 

main  data  requirements  include  the  accuracy  with  which  own- 
ship's  true  geographic  position  is  fixed,  the  "acceptable" 
navigation  error,  the  error  required  to  elicit  a  navigation 
correction  response  from  the  TRK  SUP,  the  frequency  with 
which  navigation  position  is  checked  for  accuracy,  and  the 
relative  merits  of  "automatic  real-time  navigation"  proce¬ 
dures  and  the  manual,  or  traditional,  navigation  procedures. 
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(C)  The  required  data  is  available  and  can  be  readily  ob¬ 
tained  when  own-ship  is  within  radar  range  of  land.  There 
is  no  known  method  of  verifying  navigation  accuracy  when 
own-ship  is  beyond  radar  range  of  land. 

(C)  The  following  procedures  are  used  in  Geographic  Posi¬ 
tioning.  The  Position  of  Intended  Movement  (PIM)  symbol  is 
used  to  mark  navigation  points  when  the  "real-time"  naviga¬ 
tion  procedure  is  used.  To  enable  the  Data  Recording  System 
(DRS)  to  record  navigation  information,  it  is  necessary  to 
identify  the  MPIM  tracks"  being  used  as  navigation  points. 
PIM  may  either  be  entered  by  GPFC  or  by  navigation  keyset 
entry.  The  determination  of  whether  a  PIM  track  is  being 
used  to  mark  PIM  or  to  mark  a  navigation  position  is  some¬ 
what  equivocal.  Any  track  for  which  the  following  sequence 
of  actions  is  taken  by  SWC  or  TRK  SUP  will  be  tentatively 
identified  as  a  PIM  symbol  being  used  as  a  navigation  point 
marker:  Hook,  Ball  Tab  Enable,  enter  Mode,  and  enter  the 

QAB  or  GPFC  for  Reference  Point. 

(C)  Normally,  three  or  more  navigation  points  are  used  to 
fix  own-shiprs  position;  therefore,  the  above  sequence  of 
actions  will  occur  three  or  more  times  (other  actions,  not 
related  to  navigation,  may  occur  between  each  sequence). 
Following  the  third  (or  last)  repetition  of  the  sequence, 
the  following  sequence  of  actions  will  occur  (regardless  of 
whether  PIM  was  entered  at  the  navigation  keyset  or  by  GPFC 
entry):  the  SWC  or  TRK  SUP  will  Hook  one  of  the  PIM  symbols 

enable  the  Ball  Tab,  and  enter  the  GPFC  for  Geographic  Re¬ 
position  (this  latter  sequence  may  be  repeated  one  or  more 
times) . 

(C)  Once  the  PIM  symbols  have  been  entered  and  identified 
as  navigation  point  markers,  it  will  be  possible  to  obtain 
data  on  navigation  accuracy.  This  will  be  accomplished  by 
noting  the  initial  and  final  position  of  the  Ball  Tab  when¬ 
ever  the  following  sequence  of  actions  occur:  Hook  one  of 
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the  PIM  symbols,  enable  Ball  Tab,  enter  GPFC  for  Geographic 
Reposition.  The  displacement  (in  range  and  bearing)  between 
the  initial  and  final  ball  tab  position  is  equivalent  to 
navigation  error. 

(C)  Not  all  ships  use  the  real-time  navigation  procedure. 
IVhen  it  is  not  being  used  by  ship’s  company,  it  will  be 
necessary  to  have  an  observer,  stationed  at  a  console,  who 
would  use  the  procedure  to  determine  and  record  navigation 
e  rro  rs . 

(C)  The  following  reduced  data  will  be  required  to  evaluate 
the  Geographic  Positioning  task: 

1.  The  number  of  ships  that  use  the  ’’automatic  real¬ 
time  navigation”  procedure  and  the  number  that 

do  not. 

2.  The  accuracy  of  navigation  using  the  automatic 
real-time  navigation  as  compared  to  manual 

n  avi gat i on . 

3.  The  average  size  of  navigation  error  required  to 
elicit  a  navigation  correction  response  from 
SWC  or  TRK  SUP  when  own-ship  is  within  (ten- 
tatively)  10  miles  of  land,  11-20  miles,  21-30 
miles,  31  miles  to  the  limit  of  radar  land  fall, 
and  when  own-ship  is  beyond  radar  range  of  land. 

4.  The  relationship  between  navigation  error  and 
gridlock  error  (see  gridlock  data  requirement). 

(C)  Mission-Support  Task  2:  Gridlock .  The  main  data  re¬ 
quirements  include  the  accuracy  xvith  which  gridlock  is 
maintained,  the  "acceptable"  gridlock  error,  the  gridlock 
error  required  to  elicit  a  correction  response  from  TRK  SUP, 
the  frequency  with  which  the  accuracy  of  gridlock  is  checked, 
the  number  of  mutual  tracks  required  to  maintain  a  satisfac¬ 
tory  gridlock,  the  effect  on  gridlock  accuracy  of  variable 
range  separation  between  Participating  Units  (PUs),  the 
effect  of  multiple  PUs,  2,  3,  4...n,  on  gridlock,  the  status 

of  track  correlation  before  own-ship  enters  the  data  link, 
and  the  time  required  to  establish  or  check  gridlock. 
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(C)  All  the  data  required  to  evaluate  Gridlock  performance 
can  be  obtained  by  the  DRS.  The  DRS  will  record  the  initial 
and  final  x-y  positions  of  the  Ball  Tab  whenever  it  is 
enabled  following  D/A  REM  during  the  following  sequence  of 
actions:  Hook  (mutual  track),  D/A  REM,  enable  Ball  Tab, 

enter  GPFC  for  Manual  Gridlock.  The  Ball  Tab  will  be  rolled 
from  the  center  of  the  Hook  symbol  to  the  remote  position  of 
the  mutual  track--this  distance  determines  the  magnitude  of 
gridlock  error. 

(C)  The  following  reduced  data  will  be  required  to  evaluate 
the  Gridlock  task: 

1.  The  magnitude  of  gridlock  error  by: 

a .  Time . 

b.  Total  number  of  system  tracks. 

c.  The  number  of  unknown  and  hostile  system  tracks. 

d.  The  number  of  PUs . 

e.  The  distance  between  own-ship  and  the  Gridlock 
Reference  Ship  (GRS) . 

f.  Whether  GRS  is  held  by  own-ship's  surface-search 
radar  or  other  PUs. 

g.  The  number  of  mutual  tracks  between  own-ship 
and  the  GRS . 

2.  The  frequency  with  which  gridlock  is  checked;  that 
is,  the  frequency  with  which  TRK  SUP  uses  the 

D/A  REM  QAB. 

3.  The  number  of  times  that  track  correlation  is 
attempted  prior  to  entering  an  established  data 
link  net  and  the  number  of  times  it  is  not. 

Track  correlation  will  be  said  to  have  been  at¬ 
tempted  whenever  the  following  sequence  of  button 
actions  occur:  Clear  Gridlock  Pads,  GPFC,  Hook 
(remote  track).  Ball  Tab  (video),  Manual  Gridlock 
GPFC,  D/A  REM,  Hook  (remote  track),  Position 
Correction  (remote  track),  Hook  (local  track), 

Drop  (local  track).  This  procedure  is  known  as 
taking  remote  tracks  into  local  stores.  The 
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actions  following  Clear  Gridlock  Pads  may  be 
repeated  several  times  in  succession,  once  for 
each  remote  track  taken  into  local  stores. 


4.  The  time  required  to  establish  gridlock;  that 
is,  the  elapsed  time  between  Clear  Pads  and  the 
final  Drop  local  track  actions. 

5.  The  time  required  to  check  gridlock;  that  is, 
the  elapsed  time  between  initiation  and  comple¬ 
tion  of  the  D/A  REM  function. 


(C)  Mission-Support  Task  3:  Track  Supervision .  The  main 
data  requirements  include  the  frequency  and  duration  of 
trouble  tracks,  the  frequency  and  duration  of  track  con¬ 
fusions,  the  accuracy  of  DET/TRK  performance,  and  the  super¬ 
visory  behavior  of  the  TRK  SUP. 


(C)  Data  on  the  frequency  and  duration  of  trouble  tracks 
can  be  obtained  by  the  DRS .  The  DRS  will  record  the  elapsed 
times  between  Position  Corrections  on  each  track:  whenever 
the  elapsed  time  between  Position  Corrections  on  a  particular 
track  exceeds  72  seconds,  a  trouble  track  condition  exists. 


(C)  It  is  expected  that  analyses  of  the  x-y  plots  of  given 
situations  will  reveal  most,  if  not  all,  incidents  cf  track 
confusion.  For  example,  perhaps  the  most  troublesome  track 
confusion  is  dual  designation  (different  track  numbers 
assigned  to  the  same  track).  If  the  dual  designation  is 
detected  by  the  TRK  SUP,  an  x-y  plot  would  show  a  "track 
fragment";  that  is,  a  track  was  entered,  was  retained  in  the 
system  for  a  while,  and  then  was  dropped  for  no  apparent 
reason.  If  the  Drop  Track  action  is  taken  soon  after  a  grid¬ 
lock  check  or  correction,  this  would  tend  to  confirm  that 
the  dropped  track  had  indeed  been  a  bogus  or  invalid  track 
resulting  from  gridlock  error,  the  most  common  cause  of  dual 
desi gnati ons . 

(C)  Other  indications  of  the  supervisory  behavior  of  the 
TRK  SUP  can  be  recorded  by  the  DRS.  For  example,  the  fre¬ 
quency  of  Track  History  requests  by  the  TRK  SUP  for  each 
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DET/TRK  under  his  control  would  indicate  both  the  level  of 
supervision  of  DET/TRKs  and  the  need  for  it.  An  observer 
could  directly  observe  the  TRK  SUP  and  monitor  his  com¬ 
munications.  Judgments  of  DET/TRK  detecting  and  tracking 
performance  and  of  TRK  SUP  supervisory  performance  and  task 
difficulty  may  be  obtained.  The  Track  Supervision  task  is 
an  important  one;  how  well  it  is  performed  will  likely  sig¬ 
nificantly  affect  overall  mission  performance  effectiveness. 

(C)  The  following  reduced  data  will  be  required  to  evaluate 
the  Track  Supervision  task: 

1.  Annotated  x-y  track  plot  by  situations. 

2.  Frequency  of  trouble  tracks. 

3.  Time  to  eliminate  trouble  tracks. 

4.  Frequency  of  track  confusions  by  type  of 
conf  us  ion . 

5.  Time  to  resolve  track  confusion. 

6.  Frequency  of  Track  History  requests  by 
operator . 

7.  Scaling  of  DET/TRK  and  TRK  SUP  performance 
measures . 

8.  Scaling  of  Track  Supervision  task  difficulty 
me  asures . 
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SELECTED  NTDS  GLOSSARY 


Airborne  Tactical  Data  System  (ATDS) 

An  automated  tactical  data  system,  installed  in  aircraft, 
capable  of  exchanging  data,  via  Link-11,  with  other  Tac¬ 
tical  Data  Systems.  ATDS -equipped  aircraft  are  used  in 
Airborne  Early  Warning  operations,  and  are  also  capable 
of  intercept  control  by  voice  radio  or  Link-^A. 

Alert 

Console  alerts  are  any  event  or  condition  brought  to  the 
attention  of  console  operators  by  means  of  visual  or 
audible  warnings . 

Ball  Tab 

1.  A  small  circular  symbol,  1/8"  in  diameter,  used  by 
the  operator  to  designate  position  cn  PPI  scope  and 
to  the  computer. 

2.  As  an  action.  Ball  Tab  is  the  means  by  which  the 
operator  can  designate  position  on  the  PPI  to  the 
computer  program.  The  Ball  Tab  is  "rolled"  to  the 
desired  location  by  use  of  the  Track  Ball. 

Break  Engage 

1.  An  order  to  stop  an  engagement  between  a  particular 
weapon  and  a  particular  target. 

2.  The  alert  generated  by  the  above  action. 

CANT CO  (CANNOT  COMPLY) 

1.  A  Link-11  message  initiated  by  function  code  action 
by  SWC  in  response  to  a  Flag  Order  informing  FWC 


that  SWC  is  unable  to  carry  out  the  Flag  Order;  also 
the  alert  generated  at  the  FWC  console  by  receipt  of 
CANT CO  from  SWC. 
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Cease  Fixe 

1.  An  order  to  stop  firing  all  weapons  at  a  particular 
target . 

2.  The  alert  generated  by  the  above  action. 

Central  Track  Stores  Locator  (CTSL) 

A  number  used  by  own-ship's  computer  for  referencing 
local  tracks.  CTSL  is  the  track  number  displayed  at  an 
operator  console  if  no  System  Track  Number  has  been 
assigned. 

Close  Control 

Any  symbol  displayed  within  the  Hook  symbol,  and  thus 
designated  by  the  computer  program,  is  said  to  be  in 
"close  control."  Operators  can  only  take  action  on 
tracks  in  close  control. 

Combat  Air  Patrol  (CAP) 

Aircraft,  usually  fighters,  used  to  protect  a  force  from 
enemy  air  attack.  The  CAP  also  conducts  search  operations 
acts  as  a  radio  relay,  investigates  contacts,  and  makes 
weather  observations. 

Combat  Air  Patrol  Station 

The  designated  position  for  CAP,  which  may  be  relative  to 
a  force  or  an  objective  area. 

Combat  In  format i on /De t e ct i on  Net  (CID) 

A  voice  radio  net  used  for  combat  information  and  detec¬ 
tion  reporting  among  ships. 

Data  Link  Reference  Point  (DLRP) 

A  fixed  geographic  point  used  to  mark  the  origin  of  the 
reporting  grid. 
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Data  Readout  (DRO) 


A  matrix  of  display  windows  used  to  provide  amplifying 
information  pertinent  to  the  track  in  close  control. 

Detector  (DET) 

This  operator  performs  a  search  function  and  enters  new 
tracks  into  the  system.  The  DET  tracks  contacts  until 
they  become  firm  track.  This  mode  is  infrequently  used 
in  the  Fleet  today.  The  function  of  DET  and  Tracker  have 
been  combined  into  a  single  task. 

Dynamic  Modular  Replacement  (DMR) 

A  modular  programming  concept  which  allows  modification 
of  an  NTDS  operational  program  while  it  is  running. 

DRO 


Data  Readout 
Engage 

1.  With  respect  to  missiles,  or  other  surface- 1 aunched 
weapons,  this  is  an  order  to  engage  the  target  with 
intent  to  destroy  it. 

2.  With  respect  to  interceptors  or  other  airborne 
weapon  systems,  it  is  the  order  to  commence  attack 
on  a  target. 

3.  In  the  past  tense,  engaged  is  interpreted  to  be  that 
point  in  the  engagement  process  where: 

a.  Missiles :  The  system  is  tracking,  locked-on, 
and  the  order  to  fire  has  been  given. 

b.  Airborne  Systems:  Initial  vector  has  been 

given,  and  orders  to  conduct  the  engagement  have 
been  issued. 

FCSC 

Fire  Control  System  Coordinator.  Though  a  member  of  the 
weapons  direction  team,  the  FCSC  operates  an  NTDS-like 
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console.  FCSC  acts  as  an  interface  between  CIC  and 
weapons  contro 1 . 

v/ 

Firm  Track 

1.  An  established  track. 

2.  A  tentative  track  becomes  firm  when  it  has  been  up¬ 
dated  ,3  times  or  just  once  if  the  track  was  initially 
entered  as  a  Late  Detect. 

3.  Firm  track  symbology  is  displayed  on  all  own-ship 
consoles  and  is  transmitted  over  the  data  link. 

Flag  Order 

1.  A  Link-11  message  initiated  by  FWC  when  directing 
weapons  assignments/engagements  of  force  units. 

2.  Also  the  alert  generated  at  SWC  Console  upon  receipt 
of  FWC  Flag  Order  message. 

Force  Weapon  Coordinator  (FWC) 

The  Force  Weapon  Coordinator  is  responsible  for  the  re¬ 
view  and  evaluation  of  the  overall  tactical  situation, 
and  for  the  coordination  of  combined  force  weapons  to 
achieve  the  most  effective  force  defense. 

General  Purpose  Function  Code  (GPFC) 

A  series  of  codes  used  to  supplement  the  Quick  Action 
Buttons.  They  are  used  to  enter  data  or  to  provide 
special  system  capabilities,  not  normally  required  as 
often  as  those  controlled  by  the  QABs . 

Gridlock 

The  process  of  referencing  P.U.!s  and  consequently  their 
track  reports  to  a  common  reference  point  within  a  grid 
system. 

1  Hook 

1.  A  circular  symbol,  l/2n  in  diameter,  used  by  the 
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computer  to  designate  tracks  to  the  operator  on  the 
PPI  . 

2.  As  an  action.  Hook  is  a  means  by  which  the  operator 
can  place  a  particular  track  in  Close  Control. 

1  Identification  (ID) 

The  operator  responsible  for  establishing  identity, 
category,  and  class  of  all  tracks  in  own-ship’s  area  of 
surveillance  responsibility.  Also  the  procedures  used 
to  identify  tracks. 

Intercept  Controller  (IC) 

The  Intercept  Controller  directs  the  flight  of  inter¬ 
ceptor  aircraft,  on  both  intercept  and  n on - in t e r cep t 
missions.  He  is  responsible  to  the  Ship  Weapon  Co¬ 
ordinator  (SWC)  for  the  effectiveness  of  intercepts. 

Interceptor 

An  aircraft,  usually  a  fighter,  used  to  intercept  (iden¬ 
tify  or  destroy)  assigned  targets. 

Late  Detection 

A  track  which,  when  detected  is  close  enough  to  own-ship 
to  warrant  immediate  attention.  Any  track  initially  de¬ 
tected  and  entered  in  the  system  within  some  arbitrary 
distance  from  own-ship  (usually  50  or  60  miles)  is  auto¬ 
matically  considered  a  Late  Detect.  Any  track,  at  any 
range,  may  be  entered  as  a  Late  Detect  by  QAB  action. 

u  Link  -  4 A 

A  UHF  digital  data  communications  link  to  provide  auto¬ 
matic  control  of  aircraft. 


Link-  11 


A  high-speed  digital  data  communications  link  which  pro¬ 
vides  automatic  exchange  of  real-time  tactical  information 
between  NTDS  PUs . 


Link-14 

A  teletype  communication  net  used  to  provide  semi¬ 
automatic,  computer- contro 1  led ,  one-way  transmission 
of  NTDS-evaluated  track  and  status  data  from  NTDS  to 
non-NTDS  units . 

/ 

Local  Track 

Any  track  being  tracked  by  own-ship. 

Mutual  Track 

A  track  being  tracked  both  locally  and  by  another  TDS 
unit. 

Number  Entry  Dials  or  Keyboard 

The  dials  or  buttons  on  NTDS  consoles  used  to  select 
Function  Codes  or  to  enter  data. 

y 

OTC 

(Officer  in  Tactical  Command 
Pairing 

The  assignment  of  a  weapon  to  a  target. 

Pairing  Line 

A  line  displayed  on  a  console  PPI  connecting  a  friendly 
track  symbol  (weapon  system)  and  the  symbol  of  the  track 
(target)  to  which  it  is  assigned. 

y 

Participating  Unit  (PU) 

An  NTDS  unit  participating  in  a  Link-11  net. 

Ping  Pong 

Radio  net  brevity  code  word  for  Link-11  communications. 
Used  in  conjunction  with  an  adjective  to  describe  the 
status  of  Link-11  operations. 


A-  7 


•  •  • 


•  •  • 


CJ§N»QEtfriAL.; 


•  •  ••••  •••  ••••  ••• 


• • •  • • •• 


•  •  • 


•••  ••••  ••• 


Pointer 

A  communications  symbol  (one-half  inch  square)  used  by 
one  console  operator  in  conjunction  with  NTDS  communica¬ 
tions  panel  to  direct  the  attention  of  another  console 
operator  to  a  position  on  his  PPI. 

Position  Correction  (POS  CORR) 

The  process  of  updating  track  positions. 

Quick  Action  Button  (QAB) 

QABs  provide  a  means  of  rapid  communication  with  the 
program;  the  function  of  these  buttons  is  dependent 
upon  the  particular  mode  selected  at  a  console. 

Real  Time 

1.  Pertaining  to  the  actual  time  during  which  a  physical 
process  takes  place. 

2,  Without  degradation  due  to  time  delay. 

Remote  Track 

Tracks  reported  to  own-ship  by  other  units  by  Link-11, 
but  not  held  on  own-ship's  radars. 

Reporting  Responsibility 

Reporting  Responsibility  for  a  given  track  is  automatically 
assigned  to  the  PU  having  the  best  Track  Quality  for  that 
track . 

Reposition 

An  action  that  moves  a  Hooked  track  to  the  location 
designated  by  the  Ball  Tab.  This  action  does  not  con¬ 
stitute  a  track  update. 

Sequencing 

An  action  which  causes  a  console  to  sequence  from  one 
track  to  another.  Also  the  QAB  that  accomplishes  se¬ 
quencing. 
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Selective  Identification  Feature  (SJ.F) 


A  procedure  and  system  used  to  identify  specific  friendly 
ai r craft . 

Ship  Weapon  Coordinator  (SWC) 

A  mode  of  Data  Utilization  Display  Console  operation  which 
provides  the  capabilities  for  carrying  out  Force  Weapons 
Coordinator's  orders.  In  addition,  the  operator  is  respon¬ 
sible  for  review  and  evaluation  of  own-ship's  tactical 
situation  and  for  the  direction  of  own-ship's  weapons. 

Split 

The  separation  of  a  single  radar  return  into  two  or  more 
tracks.  Also  the  QAB  used  to  enter  Splits. 

Symb  o 1 

An  electronically  generated  shape  displayed  on  the  PPI  to 
represent  targets,  interceptors,  air  tracks,  surface 
tracks,  or  special  points. 

^System  Track 

A  track  being  reported  or  received  over  Link-11. 

System  Track  Number  (STN,  TN) 

A  unique  four-digit  octal  number  used  in  NTDS  data  link 
communications  to  identify  and  reference  each  track  in 
the  system. 

DS 


Tactical  Data  Systems 
^Tentative  Track 

A  track  that  has  been  entered  into  the  system  but  has  not 
yet  been  updated  a  sufficient  number  of  times  to  be  a  firm 
track.  Denoted  by  Tentative  Track  Symbol  which  is  pre¬ 
sented  only  on  INPUT  consoles  and  is  not  transmitted  over 
data  link. 
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Track  Ball 


The  device  which  controls  the  movement  of  the  Ball  Tab. 


/Track  Category 

In  NTDS,  the  track  categories  are:  Air,  Surface,  Sub¬ 
surface,  and  Special  Points. 

Track  Classification 

In  NTDS ,  the  track  classifications  are:  Airborne  Early 
Warning,  Anti-Submarine  Warfare  Aircraft,  Interceptor, 
Strike  Aircraft,  Carrier,  Missile  ship.  Picket  (DD) ,  Pos¬ 
sible  Submarine,  Probable  Submarine,  Positive  Submarine. 

^  Tracke r 

Console  operator  who  updates  firm  tracks.  This  function 
is  typically  combined  with  the  DET  task.  An  operator 
designated  as  a  DET/TRK  uses  the  tracker  mode  of  console 
operation. 

Track  History 

A  series  of  the  most  recent  updates  of  a  track  which  may 
be  displayed  on  a  console  PPI  at  the  operator's  request. 

/Track  Quality 

A  numerical  value,  assigned  to  a  track,  computed  from 
values  related  to  the  past  tracking  performance  on  the 
track.  Track  Quality  is  used  in  determining  Link-11 
Reporting  Responsibility. 

/Track  Supervisor  (TRK  SUP) 

A  mode  of  Data  Input  Display  Console  operation.  The 
operator  monitors  and  supervises  the  overall  performance 
of  all  the  NTDS  INPUT  functions. 


Utility  Mode 

A  mode  of  console  operation  that  can  be  used  by  any 
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operator  to  temporarily  add  additional  capabilities  to 
those  normally  available  to  him.  Typically  an  operator 
switches  to  the  Utility  Mode,  performs  a  specific  func¬ 
tion,  and  then  switches  back  to  his  original  mode. 

Vital  Area 

The  area  wherein  the  protected  force  is  located.  The 
size  of  the  Vital  Area  is  a  function  of  number  and 
disposition  of  units  in  the  protected  force  and  the 
capabilities  of  available  force  defensive  weapons. 
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General 


The  FWC  acts  for  the  Officer  in  Tactical  Command  (OTC) 
and  is  responsible  to  him  for  evaluation  of  the  force  tacti¬ 
cal  situation,  and  for  the  combat  direction  of  force  weapons. 
In  contrast  to  conventional  (non-NTDS)  task  groups  where  the 
OTC  usually  delegates  the  duty  of  Force  AAW  Commander  to  a 
subordinate  commander,  the  NTDS  OTC  usually  exercises  this 
responsibility  himself  (through  a  senior  member  of  his  staff 
acting  as  FWC) • 

FWC  is  responsible  for: 

1.  Determining  the  threat  to  the  force  of  each  target 
(all  tracks  not  identified  as  confirmed  friend  are 
considered  targets) . 

2.  Selecting  the  most  appropriate  weapon(s)  to  counter 
e  ach  t  arge t . 

3.  Directing  the  force  Ship  Weapons  Coordinator  (SWC) 

to  engage  designated  targets  with  selected  weapon(s). 

4.  Ordering  Break  Engage  and  Cease  Fire. 

Detailed  Task  Description 

FWC  selects  targets  for  engagement  on  a  threat  basis. 

The  most  threatening  targets  are  engaged  first.  FWC  uses 
system  computed  threat  values  plus  indications  available 
from  his  PPI  and  DRO  displays  to  select  targets.  Weapons 
assignments  are  made  in  conformance  with  the  concept  of  De¬ 
fense  in  Depth.  Several  lines  of  defense  are  established 
along  the  threat  axis.  For  example,  three  lines  of  defense 
might  consist  of  interceptors,  long-range  missiles,  and 
short-range  missiles.  An  attempt  would  be  made  to  have  each 
line  of  defense  engage  and  destroy  as  many  incoming  targets 
as  possible.  In  theory,  each  succeeding  line  of  defense 
would  have  fewer  and  fewer  targets  to  deal  with. 


FWC  orders  engagements  by  Hooking  a  target.  Ball  Tabbing 
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Engage  Missile  Quick  Action  Button  (QAB) .  If  a  ship  is  con¬ 
trolling  more  than  one  interceptor,  FWC  may  Ball  Tab  a  spe¬ 
cific  interceptor  or  he  in  ay  Ball  Tab  the  ship  and  let  the 
ship's  S IV C  decide  which  interceptor  to  use. 

In  any  event,  when  FWC  presses  an  engagement  QAB,  a 
pairing  line  connecting  the  selected  target  and  weapon  and 
a  Flag  Order  are  transmitted  via  Link  11  to  the  ship  con¬ 
trolling  the  selected  weapon. 

The  SWC  then  issues  the  necessary  orders  to  complete 
the  engagement.  If  SWC  is  unable  to  comply  with  FWC's  order 
he  responds  by  entering  the  General  Purpose  Function  Code 
(GPFC)  for  Cannot  Comply.  The  Cannot  Comply  response  would 
generate  an  alert  at  FWC's  console  and  he  would  then  select 
another  weapon  to  engage  the  target. 

FWC  has  QABs  that  can  be  used  to  order  Cease  Fire  and 
Break  En gage . 

FWC  observes  the  progress  of  engagements  by  monitoring 
his  PPI  and  observing  the  changes  in  engagement  symbology 
as  they  occur. 

SHIP  WEAPONS  COORDINATOR  (SWC)  TASK  DESCRIPTION 
General 

The  SWC  is  responsible  for  the  combat  direction  of  own- 
ship's  weapons.  SWC  directs  engagements  of  own-ship's  weapons 
either  in  response  to  the  Force  Weapons  Coordinator's  orders 
or  on  his  own  initiative.  SWC  continuously  evaluates  own- 
ship's  tactical  situation  by  observing  the  indications  presented 
to  him  on  his  PPI  and  DRO  displays. 

Other  SWC  duties  include  supervising  of  the  other  NTDS 
operators  and  managing  the  configuration  of  own-ship's  com¬ 
puter  program. 
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SWC's  weapons  direction  task  consists  of  two  parts-- 
target  selection  and  weapon (s)  selection.  The  weapons  avail¬ 
able  to  SWC  are  own-ship's  missiles  and  interceptor  aircraft, 
when  assigned. 


When  multiple  targets  are  present,  SWC  attempts  to  en¬ 
gage  the  most  threatening  target  first.  He  would  also  like 
to  engage  the  targets  as  far  from  own-ship  as  possible  for 
two  reasons:  (1)  to  destroy  the  target  before  it  reaches 

its  weapon  release  point,  and  (2)  to  have  a  second  shot  at 
it  if  the  target  should  survive  the  initial  engagement.  For 
both  of  these  reasons,  SWC  would  prefer  to  engage  the  target 
initially  with  interceptors. 

The  procedural  aspects  of  the  SWC's  weapons  direction 
task  are  straightforward.  To  engage  a  target  with  an  inter¬ 
ceptor  he  Hooks  the  selected  target  (places  it  in  close  con¬ 
trol),  Ball  Tabs  the  interceptor,  and  presses  the  Engage 
Interceptor  Quick  Action  Button  (QAB) .  These  actions  gener¬ 
ate  a  Target  Assigned  alert  at  the  Intercept  Control  (IC) 
console . 


To  engage  a  target  with  own-ship's  missiles,  SWC  Hooks 
the  target  and  presses  his  Engage  Missile  QAB.  These  actions 
generate  a  Target  Assigned  alert  at  the  Fire  Control  System 
Coordinator's  (FCSC)  console. 

If  the  target  can  be  engaged  by  the  weapon  selected, 
trial  geometry  is  displayed  on  SWC's  PPI  and  the  DRO  display 
indicates  time-to-go-to-intercept.  If  the  intercept  is  not 
possible,  the  DRO  reads  out  Poor  Situation.  Assuming  the 
intercept  is  possible,  the  SWC  must  decide  whether  to  go 
ahead  with  it.  For  example,  if  an  interceptor  had  been  se¬ 
lected,  the  factors  that  would  influence  SWC's  decision 
would  be  time-to-go,  and  proximity  of  intercept  point  to  own- 
ship's  missile  envelope. 
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If  the  intercept  could  not  be  completed  beyond  own- 

ship's  missile  envelope,  SWC  would  probably  decide  to  use 
missiles  instead  of  the  interceptor. 


Ideally,  ail  targets  would  be  engaged  before  they  en¬ 
tered  the  Vital  Area.  In  any  event,  an  attempt  would  be  made 
to  engage  and  destroy  every  target  before  it  reached  its 
Weapon  Release  Point  (the  drop  point  for  a  gravity  bomb  or 
the  firing  point  for  an  Ai r- t o- Surf ace  Missile  (ASM). 

If  an  engagement  is  initiated  but  the  SWC  decides  to 
abort  it  prior  to  its  completion,  he  presses  the  Cease  Fire 
or  Break  Engage  QAB.  Cease  Fire  is  used  to  order  all  own- 
ship's  weapons  to  cease  fire  on  the  target  in  close  control 
at  the  SWC  console.  Break  Engage  is  used  to  order  a  partic¬ 
ular  weapon  to  cease  fire. 

Supervision  of  Other  Operators 


For  the  most  part,  SWC's  supervision  of  the  other  NTDS 
operations  is  management  by  exception.  He  gets  directly  in¬ 
volved  only  when  he  observes  unsatisfactory  performance. 

The  frequency  with  which  he  is  required  to  intervene 
varies  considerably  depending  on  his  experience  and  pro¬ 
ficiency,  the  experience  and  profiency  of  the  other  opera¬ 
tors,  and  the  tactical  situation. 


Management  of  the  OMR 

Dynamic  Modular  Replacement  (DMR)  is  a  relatively  new 
concept  in  NTDS  programming.  DMR  is  designed  to  provide  NTDS 
with  a  better  capability  to  handle  the  task  at  hand  while 
sacrificing,  momentarily,  some  system  flexibility. 


The  DMR  consists  of  a  Resident  Module  and  several  Tran¬ 
sient  Modules.  The  Resident  Module  is  the  basic  NTDS  operating 
program  and  remains  in  core  at  all  times.  The  Transient  Mod¬ 
ules  are  designed  to  provide  the  system  with  special  capabilities 
The  Transient  Modules  can  be  added  or  deleted  while  the  program 
is  runnin8 •  . .  . 
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TRANSIENT  MODULES 


Name 

Numb  e  r 

Version 

Size 

■('#'  Cells) 

1 . 

Height  Size  (HSA) 

10 

1 

2290 

2  . 

Intercept  Control  (IC) 

14 

0 

4824 

3. 

Intercept  Control  (ICA) 

14 

1 

3764 

4. 

Intercept  Vectoring  (IV) 

14 

2 

3289 

5  . 

Electronic  Warfare  (EW) 

15 

0 

2395 

6  . 

Electronic  Warfare  (EWA) 

15 

1 

2565 

7. 

Surface  Maneuvering  (SM) 

16 

0 

155  1 

8. 

Link  14  (BL) 

25 

0 

2471 

9  . 

Link  4 A  (LF) 

26 

0 

1103 

10  . 

Training  (TB) 

35 

0 

3439 

1  1  . 

Aircraft  Data  Entry  (AE) 

36 

0 

0234 

12. 

Mark  11  (MEC) 

50 

0 

5  75  2 

Transient  Modules  are  added  or 

deleted  by 

General  Purpose 

Function  Code  (GPFC)  entry. 

The  present  status 

of  the  DMR  can 

be 

called  up  and  displayed  on 

the  Data  Readout 

(DRO) .  Modules 

are 

added  and  deleted  so  as  to  match 

system  capabilities  with 

the  requirements  of  the  existing  operational  situation. 


INTERCEPT  CONTROLLER  (IC)  TASK  DESCRIPTION 


General 

The  IC's  primary  responsibility  is  to  control  aircraft 
on  intercept  and  other  type  missions.  Usually  the  IC  acts  in 
response  to  SWC  orders  but  may  act  on  his  own  initiative  to 
counter  an  immediate  threat. 


During  normal  Anti-Air  Warfare  (AAW)  operations,  inter- 
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usually  1  oc«r?e«d#irr ••advsm tv  o*f?*tlte#  CaS*k*^f  oVp  £lo*ng##the  threat 
axis.  When  an  incoming  raid  (one  or  more  hostile  aircraft) 
is  detected,  the  Force  Weapons  Coordinator  (FWC)  will  desig¬ 
nate  which  targets  are  to  be  engaged  by  which  weapons.  His 
decision  will  be  transmitted  to  Participating  Units  (PU)  via 
Link  11  in  the  form  of  engagement  Flag  Orders.  The  SlVC(s) 
acting  either  in  response  to  such  an  FWC  order  or  on  his  own 
initiative  will  select  an  own-ship  weapon  to  engage  each 
target  in  his  zone  of  responsibility.  If  he  decides  to  en¬ 
gage  a  target  with  an  interceptor,  he  will  press  his  Engage 
Interceptor  Quick  Action  Button  (QAB) ,  thus  sending  a  Target 
Assigned  Alert  to  the  air  controller  controlling  the  par¬ 
ticular  interceptor  to  be  used  in  the  intercept. 


Detailed  Task  Description 


The  IC  responds  to  the  Target  Assigned  Alert  by  pressing 
his  Sequence  QAB.  This  places  his  interceptor  in  close  con¬ 
trol  and  a  pairing  line  is  displayed  on  his  PPI  connecting 
his  interceptor  and  the  designated  target. 

The  IC  presses  the  QAB  appropriate  for  a  Pursuit  or 
Collision  intercept.  This  action  calls  up  trial  geometry  for 
the  desired  type  of  intercept.  The  IC  attempts  to  complete 
the  intercept  as  expeditiously  as  possible  and  as  far  from 
own-ship  or  Vita]  Area  as  possible.  With  these  objectives 
in  mind,  the  IC  selects  the  geometry  he  considers  best  on  the 
basis  of  t i me - t o - go - t o- i n t e r cep t ,  and  the  distance  of  the 
point  of  intercept  from  own-ship  or  the  Vital  Area.  As  soon 
as  the  IC  has  made  his  choice  and  sent  his  first  control  order 
to  the  interceptor  (via  voice  radio),  he  presses  Order  Sent. 
The  Order  Sent  button  action  causes  a  change  in  the  engagement 
symbology  which  is  transmitted  over  the  data  link  to  inform 
FWC  and  all  PUs  that  the  target  is  being  engaged. 

If  the  interceptor  is  equipped  with  a  Link  4A  receiver, 
a  device  designed  to  permit  air  control  orders  to  be  sent  to 
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tude  orders  are  initiated  by  the  Order  Sent  button  action. 

The  air  controller  reevaluates  the  intercept  and  sends 
"bogie  dope"  (range  and  bearing  of  target  from  interceptor) 
to  the  aircraft  every  10  seconds  (once  every  radar  sweep). 

On  each  sweep  of  the  radar,  the  IC  Position  Corrects  (tracks) 
his  interceptor  and  the  target.  He  checks  to  ensure  that  the 
interceptor  is  flying  the  ordered  course  (by  comparing  the 
position  of  the  interceptor  symbol,  which  is  being  dead 
reckoned  at  ordered  course  and  speed,  and  the  position  of  the 
interceptor's  video). 

During  an  intercept,  the  IC  has,  in  essence,  two  sequen¬ 
tial  tasks  to  perform.  These  might  be  called  course  and 
precision  control.  During  course  control,  the  first  task, 
the  IC  is  concerned  with  directing  the  interceptor  into  the 
vicinity  of  the  target.  To  do  this,  the  IC  must  insure  that 
target  bearing  (from  the  interceptor)  remains  steady  and  that 
the  range  between  interceptor  and  target  is  decreasing. 

The  intercept  may  be  complicated  by  target  maneuvers, 
strong  winds,  obstacles  such  as  mountain  tops,  or  enemy 
fighter  escorts.  The  IC  must  be  alert  to  compensate  for  or 
to  minimize  the  effects  of  these  factors. 


During  the  final  or  precision  phase  of  an  intercept,  the 
air  controller  seeks  to  ensure  that  his  interceptor  will  be 
in  the  appropriate  final  position  relative  to  the  target. 

The  exact  parameters  of  the  final  position  vary  as  a  func¬ 
tion  of  the  characteristics  of  the  Air  to  Air  Missiles  (AAM) 
carried  by  the  interceptor  but  are  always  astern  and  below 
the  target.  All  intercepts  become  tail  chase  or  pursuit 
intercepts  in  their  final  stages  because  of  the  requirement 
to  release  interceptor  weapons  from  astern  of  the  target. 

When  the  intercept  is  completed,  or  if  it  is  broken  off 
before  completion,  the  IC  presses  the  Cannot  Engage  QAB  which 
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assi gnment . 


Assuming  other  hostile  targets  are  present,  SWC  may  im¬ 
mediately  assign  another  target  to  the  IC  or  the  IC  may  com¬ 
mence  a  new  intercept  on  his  own  initiative  in  the  absence  of 
an  SWC  order.  The  subsequent  target  will  be  selected  on  the 
basis  of  its  proximity  to  the  interceptor  and  to  the  protected 
force . 


TRACK  SUPERVISOR  (TRK  SUP)  TASK  DESCRIPTION 
Genera l 

The  Track  Supervisor  monitors  and  supervises  the  per¬ 
formance  of  all  own-ship  Input  operators.  In  addition,  he 
is  responsible  for  maintaining  gridlock,  monitoring  the  per¬ 
formance  of  Link  11  and  14,  and  acting  as  the  Combat  Informa¬ 
tion  and  Detection  (CID)  Net  communicator.  He  also  acts  as 
a  back-up  for  all  other  input  operators. 

Detailed  Task  Description 

1.  Designates  mode  and  radar  to  be  used  by  each  input 
op  e  r  at  o  r . 

a.  The  normal  arrangement  of  mode  and  radar  is  not 
likely  to  change  from  watch  to  watch.  The  TRK 
SUP  should,  however,  be  cognizant  of  present 
radar  performance,  fade  zones,  inversion  layers, 
etc.,  and  should  direct  a  change  in  range  scale 
if  existing  conditions  dictate. 

b.  During  a  regular  underway  watch,  the  TRK  SUP 
rotates  the  Input  operators  periodically  from 
console  to  console  (about  every  30  minutes). 
Personnel  are  rotated  infrequently  during  Gen¬ 
eral  Quarters . 

2,  Assigns  search  sectors  to  Detector/Trackers  (DET/TRK) 

The  search  sectors  are  likely  to  be  the  same  from 
watch  to  watch  and  day  to  day.  However,  if  there  is 
a  lot  of  activity  in  one  sector  and  not  in  another, 
the  TRK  SUP  may  assign  targets  in  the  loaded  sector 
to  a  DDT /TRK  who  is  not  as  busy. 
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the  DET/TRK . 

a.  To  do  so,  the  TRK  SUP  keeps  own-ship  centered 

on  his  PPI .  The  PPI  scope  and  the  Data  Readout 
(DRO)  provide  several  indications  of  TRKer 
p  erformance . 

(1)  The  TRK  SUP  can  obtain  an  overview  of  the 
tracking  situation  by  scanning  his  PPI  to 
determine  whether  each  piece  of  video  has 
been  assigned  a  symbol  and  to  check  the 
relationship  of  the  track  symbols  to  tar¬ 
get  video.  The  symbols  and  video  should  be 
continuously  superimposed  on  one  another 
and  should  be  moving  together. 

(2)  Another  indication  used  by  TRK  SUP  to  check 
on  tracking  performance  is  Track  Quality 
(TQ) .  Track  Quality  is  a  numerical  value 
(from  1  to  7)  assigned  to  each  track,  com¬ 
puted  from  values  relating  to  past  tracking 
performance.  TRK  SUP  should  insist  on  a 

TQ  of  5  or  better  on  each  track. 

(3)  The  TRK  SUP  also  uses  the  track  history  func¬ 
tion  to  monitor  tracker  performance.  Track 
history  is  a  display  of  the  position  of  the 
ball  tab  for  the  5  most  recent  track  updates. 
The  ball  tab  positions  should  form  either  a 
straight  line  or  a  smooth  curve  and  should 

be  about  equally  spaced. 

4.  Assists  DET/TRK  by  entering  new  tracks,  updating 

tracks,  and  entering  splits. 

a.  The  TRK  SUP  should  refrain  from  tracking  as 
much  as  possible.  The  more  time  the  TRK  SUP 
spends  tracking,  the  less  time  he  has  avail¬ 
able  to  attend  to  his  supervisory  tasks. 

5.  Drop  tracks  when  necessary. 

a.  Tracks  are  dropped  when  they  go  beyond  radar 
range,  or  if  they  represent  downed  aircraft, 
or  if  they  represent  bogus  or  invalid  tracks. 

6.  Uses  IFF  to  assist  in  tracking. 

a.  IFF  is  usually  used  in  tracking  at  the  request 
of  a  DET/TRK  to  help  in  resolving  the  identity 
of  merged  or  interchanged  tracks. 
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CID  net  communications. 


a.  The  amount  of  time  the  TRK  SUP  spends  on  the 
CID  net  varies  as  a  function  of  the  tactical 
situation  and  the  number  of  non-NTDS  ships  in 
the  Task  Group. 

b.  An  initial  detection  report  is  made  via  the 
CID  net  for  every  target  (this  report  serves 
as  back-up  for  the  automatic  Link  11  report). 

Monitor 


An  appreciation  of  the  monitoring  tasks  performed  by  the 
various  NTDS  operators  is  central  to  an  understanding  of  the 
real  world  of  NTDS.  NTDS  operators  refer  to  the  philosophy 
underlying  the  NTDS  monitor  task  as  check-check-check ,  i.e., 
every  operator  checks  on  the  performance  of  every  other  oper¬ 
ator.  To  illustrate,  the  primary  responsibility  for  detecting 
new  video  rests  with  the  DET/TRK  but  every  operator  assists 
in  the  search  task  and  any  operator  may  enter  a  new  track; 
the  primary  responsibility  for  selecting  targets  and  assigning 
weapons  rests  with  the  F1VC,  but  SWC  or  IC  may  initiate  engage¬ 
ments  in  the  absence  of  FWC  action.  In  the  search  task,  upper 
echelon  operators  are  checking  on  the  performance  of  the  lowest 
echelon  performer;  in  the  weapons  assignment  task,  lower  eche¬ 
lon  operators  are  checking  on  the  performance  of  a  higher 
echelon  performer. 


In  addition  to  the  monitoring  tasks  performed  by  the 
operators,  the  computer  is  also  constantly  checking  perfor¬ 
mance;  it  rejects  certain  operator  actions,  reminds  operators 
to  perform  some  overdue  actions,  alerts  operators  to  special 
situations,  and  makes  available  data  useful  for  checking  on 
past  performance. 


The  Input  operator  with  the  largest  monitoring  load  is 
the  TRK  SUP.  The  TRK  SUP's  primary  responsibilities  are  (1) 
insuring  the  Input  operators  are  performing  satisfactorily, 
and  (2)  insuring  that  the  data  transmitted  over  the  data  link 
is  accurate  and  properly  referenced. 
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tors  by  periodically  reviewing  system  tracks,  as  described  in 
3a  above . 


The  TRK  SUP  must  also  be  alert  to  detect  confused  track¬ 
ing  situations .  Confused  tracking  situations  may  result  from 
(1)  invalid  tracks  (track  symbol  not  associated  with  a  valid 
piece  of  video);  (2)  dual  designations  (two  track  numbers 
associated  with  the  same  piece  of  video);  (3)  duplicate  tracks 
(two  valid  pieces  of  video  with  the  same  track  number);  (4) 
failure  to  hand  over  tracking  responsibility  (a  necessary, 
manual  action  required  whenever  a  track  fades  from  own-ship's 
radar  but  is  still  held  on  another  Participating  Unit’s  (PU) 
radar;  failure  to  hand  over  tracking  responsibility  will 
eventually  result  in  a  runaway  track);  (5)  decorrelation 
(occurs  when  the  discrepancy  between  local  and  remote  reported 
position  of  a  system  track  exceeds  the  limit  prescribed  by 
the  program;  decorrelation  will  result  in  a  dual  designation 
and  perhaps  a  runaway  track);  (6)  interchanges  (when  tracks 
cross,  particularly  if  the  tracks  are  on  nearly  parallel 
courses,  the  system  has  a  tendency  to  exchange  track  numbers 
between  the  two  tracks);  (7)  merges  (occur  when  two  formerly 
separate  tracks  merge  into  a  single  track);  (8)  splits  (occur 
when  a  single  track,  consisting  of  two  or  more  aircraft  flying 
in  formation,  divide  and  become  two  or  more  tracks).  To 
prevent  or  correct  confused  tracking  situations,  the  TRK  SUP 
must  take  corrective  action  in  a  timely  manner. 

Another  of  the  TRK  SUP's  major  monitoring  tasks  is  ensur¬ 
ing  that  the  data  transmitted  over  Link  11  is  accurate  and 
properly  referenced.  This  task  includes  ensuring  that  own  - 
ship's  data  link  terminal  is  operating  correctly,  and  that  a 
satisfactory  gridlock  is  being  maintained. 

The  System  Monitoring  Panel,  operated  by  the  SWC,  is 
designed  to  detect  failures  of  the  data  link.  The  TRK  SUP 
by  observing  the  indications  available  from  the  Data  Link 
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detect  an  impending  failure  of  the  data  link. 

The  TRK  SUP's  task  is  to  combine,  analyze,  and  interpret 
the  available  indications  and  to  take  corrective  action  when 
it  is  cal  led  for. 

The  amount  of  time  required  to  perform  this  monitoring 
task  and,  indeed,  the  value  of  performing  it  are  unknown.  At 
least  on  some  ships,  TRK  SUP  is  advised  to  ignore  or  pay  very 
little  attention  to  this  task.  On  other  ships,  this  Is  con¬ 
sidered  to  be  among  the  TRK  SUP's  most  important  tasks.  No 
data  is  at  present  available  to  verify  whether  either  of  these 
positions  is  correct. 

Gridlock 

When  two  or  more  NTDS  ships  are  operating  together  they 
exchange  tactical  data  via  a  digital  data  link--Link  11.  An 
x-y  grid  coordinate  system  is  used  to  report/exchange  track 
position  information.  An  arbitrary,  geographic  position  is 
selected  as  the  reference  point  or  origin  of  the  grid.  This 
reference  point  is  referred  to  as  the  Data  Link  Reference 
Point  (DLRP) . 

Before  tactical  data  is  exchanged  between  units,  each 
unit  determines  its  position  in  relation  to  DLRP.  As  a 
result  of  the  appropriate  operator  button  actions,  this  re¬ 
lationship  is  entered  into  the  computer  as  a  mathematical 
constant  which  is  used  in  converting  the  range  and  bearing 
information  obtained  by  own-ship's  sensors  into  x-y  grid 
coordinate  position  information.  It  is  this  grid  coordinate 
data  that  is  exchanged  among  units  via  the  data  link. 

If  a  unit  makes  an  error  in  determining  its  relationship 
to  DLRP,  there  will  be  an  equivalent  error  in  the  track  posi¬ 
tion  information  it  reports.  Such  an  error  is  referred  to 
as  a  gridiock  error,  i.e.,  own-ship's  grid  does  not  originate 
at,  "is  not  locked  to,"  DLRP. 
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DIAGRAM  OF  GRIDLOCK  ERROR 


1.  PU1  holds  Bogie  1  on  its  radar,  but  Bogie  1  is 
beyond  the  PU2's  radar  range. 

2.  Bogie  l's  true  x-y  grid  position  is  2-1/2  west 
and  2-1/2  north.  Due  to  gridlock  error,  however, 
PU1  is  reporting  Bogie  l's  position  as  2-1/2  west 
and  3- 1/2  north . 

3.  Depending  on  the  size  of  PUl's  gridlock  error, 
which  may  be  only  a  few  thousand  yards  or  as 
much  as  tens  of  miles,  the  track  position  data 
being  reported  by  PU1  to  PU2  may  be  satisfactory, 
useless,  or  misleading. 

It  should  be  noted  that  the  gridlock  error  would  not 
affect  PUl's  ability  to  engage  Bogie  1.  Each  engagement  of 
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a  target  by  an  individual  ship  is  conducted  using  that  ship's 
sensor  information. 


In  the  diagram,  PU2  is  assumed  to  have  a  good  gridlock. 

In  reality,  of  course,  PU2  could  also  be  out  of  gridlock. 

If  this  were  so,  PU2's  gridlock  error  would  probably  compound 
the  error  in  the  reported  position  of  Bogie  1,  although  it  is 
conceivable  that  PU2's  error  could  cancel  PUl's  error.  The 
significant  point  is  that  each  unit  in  a  task  group  may  have 
incorrectly  calculated  its  relationship  to  DLRP.  That  is, 
for  example,  if  there  were  10  ships  in  a  task  group,  it  is 
conceivable  each  cou]d  be  out  of  gridlock  and  each  could  be 
reporting  erroneous  or  conflicting  data. 

The  diagram  depicts  one  of  the  key  advantages  of  NTDS 
over  conventional  CIC's,  namely  the  capability  of  NTDS  to 
display  the  real-tine  position  of  remote  tracks.  A  remote 
track  is  one  held  on  one  PU ' s  radar  but  not  on  another  PU's 
radar.  (A  mutual  track  is  one  held  by  both  PU's.)  When  a 
significant  gridlock  error  exists,  the  advantage  of  the 
remote  track  "reporting  capability  may  be  lost  or  even  prove 
detrimental  if  it  causes  excessive  track  confusion. 

Dual  designation  is  an  example  of  track  confusion.  A 
dual  designation  exists  when  two  or  more  track  numbers  are 
assigned  to  a  single  target.  The  most  common  cause  of  dual 
designations  is  gridlock  error.  Assume  Ship  A  is  tracking 
Aircraft  A.  Ship  A  is  reporting  the  position  of  Aircraft  A 
to  Ship  B  which  does  not  hold  Aircraft  A  on  its  radar.  Fur¬ 
ther  assume  that  a  significant  gridlock  error  exists,  either 
Ship  A  or  Ship  B  or  both  are  significantly  out  of  gridlock. 
Aircraft  A  is  on  a  course  that  will  take  it  into  Ship  B's 
radar  range.  When  Ship  B  finally  detects  Aircraft  A,  a  check 
will  be  made  to  determine  if  a  track  symbol  and  a  track  number 
have  previously  been  assigned  to  it.  Under  ideal  conditions, 
which  include  a  perfect  gridlock,  when  Ship  B  detects  Air- 


,*V  *W'  ~' 


•  •  •  •  •••  •  ••  •••  •••  •••  ••••  •••  ••••  ••• 

••••••  •  •••  •  ••  •  •  • 

••••••  •  •  •  ••  ••  •  •••  • 

•••••  •  ••••  •  •••  •• 

this  instance,  however,  the  ships  are  not  in  good  gridlock, 
therefore  the  symbol  will  not  be  superimposed  on  the  video. 

At  this  point  it  is  up  to  the  DET/TRK  or  the  TRK  SUP  on 
Ship  B  to  decide  whether  the  new  piece  of  video  is  Aircraft  A 
or  a  different  aircraft.  If  the  new  piece  of  video  and  the 
track  symbol  for  Aircraft  A  are  close  to  one  another  and  the 
new  piece  of  video  and  the  symbol  are  on  about  the  same 
course  and  speed,  the  decision  is  likely  to  be  that  the  new 
piece  of  video  is,  in  fact,  Aircraft  A.  If  the  symbol  and 
the  new  video  are  not  close  to  one  another,  the  decision  is 
likely  to  be  that  the  new  piece  of  video  is  not  Aircraft  A. 

Thus  the  "new”  piece  of  video  will  be  entered  into  the  system 
as  a  new  track.  We  now  have  two  track  symbols  assigned  to  a 
single  ai rcraf t . 

With  just  two  ships  and  only  one  aircraft  involved,  dual 
designation  is  perhaps  not  a  serious  problem.  It  is,  however, 
possible  (even  likely)  that  these  two  ships  will  assign  two 
track  symbols  to  every  mutual  track  they  hoid  until  the  grid¬ 
lock  error  is  resolved.  It  is  also  possible,  even  likely, 
that  if  three  ships  are  significantly  out  of  gridlock,  three 
track  symbols  will  be  assigned  to  each  mutual  track.  Obviously, 
if  ail  these  tracks  were  identified  as  hostile  it  would  be  dif¬ 
ficult  for  the  force  level  decision  maker  charged  with  the 
responsibility  for  assigning  weapons  to  efficiently  counter 
the  threat  posed  by  each  of  these  "targets." 

Actually  this  scenario  should  not  be  carried  too  far. 

Before  long  someone  would  realize  something,  probably  grid¬ 
lock,  was  wrong.  Action  would  then  be  taken  to  correct 
gridlock  and  to  resolve  the  track  confusion. 

Several  questions  arise.  How  long  is  "before  long?" 

How  likely  is  it  that  the  type  of  track  confusion  described 
will  occur  at  a  crucial  time?  Earlier  we  spoke  of  a 
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lock  error?  We  also  referred  to  the  DET/TRK  or  TRK  SUP  de¬ 
ciding  whether  he  had  one  target  or  two  based  on  whether  the 
symbol  and  the  video  are  close  to  one  another.  How  close  is 
close? 


Unfortunately,  although  there  is  much  conjecture  about 
the  answers  to  these  questions,  there  are  no  answers.  At 
least  there  do  not  seem  to  be  any  answers  based  on  hard  data. 

The  TRK  SUP  is  responsible  for  establishing  and  main¬ 
taining  gridlock.  The  procedures  for  doing  so  appear  to  be 
relatively  simple  and  straightforward.  Apparently  this 
appearance  is  deceiving.  Gridlock  error  is  repeatedly  men¬ 
tioned  as  one  of,  if  not,  the  most  common  and  significant 
problems  in  NTDS  task  group  operations. 

The  gridlocking  task  can  be  divided  into  three  sub¬ 
tasks  : 

1.  Fixing  own-ship’s  true  geographic  position  and 
thereby  own-ship’s  position  relative  to  DLRP. 

2.  Establishing  gridlock. 

3.  Maintaining  gridlock. 

The  procedural  aspects  of  these  tasks  are  adequately 
described  in  the  XTDS  documentation  and  are  unlikely  to  be 
of  much  interest  to  the  reader  of  this  report.  In  any  event, 
since  the  procedural  aspects  of  gridlocking  are  fairly 
straightforward,  the  causes  of  the  gridlock  problem  apparently 
lie  elsewhere ,  The  identification  of  those  causes  awaits  the 
kind  of  detailed  analysis  that  will  only  be  possible  when 
quantitative  data  become  available. 


IDENTIFICATION  (ID)  OPERATOR  TASK  DESCRIPTION 
General 


The  ID  operator  is  responsible  for  performing  that  portion 
of  the  identification  task  delegated  to  him  b^y  ^cony^n  d  and  for 
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The  identification  of  a  given  track  is  determined  on  the 
basis  of  (1)  Identification  Friend  or  Foe/Selected  Identifi¬ 
cation  Feature  (IFF/SIF)  information,  (2)  the  track  fs  course, 
speed,  and  altitude,  (3)  intelligence  data,  (4)  the  target's 
responses  to  ordered  maneuvers,  (5)  current  operation  orders, 
and  (6)  orders  received  from  the  Officer  in  Tactical  Command 
(OTC) . 

The  ID  operator  (1)  identifies  targets  as  friend  or  foe, 
(2)  determines  track  categories  (air,  surface,  subsurface), 
and  (3)  assigns  class  designations  (helo,  destroyer,  strike 
or  interceptor,  etc.). 

The  ID  operator  assigns  an  identification  confidence 
level  to  each  track;  unknown assumed  friend  or  hostile, 
confirmed  friend  or  hostile.  The  ID  operator  may  (1)  in¬ 
crease  his  confidence  level,  e.g.,  unkn own - t o- as s ume d- 1 o 
confirmed;  he  may  decrease  his  confidence  level,  e.g., 
con f i rme d- t o- as s ume d  (this  action  generates  an  ID  Change 
alert);  or  he  may  change  his  identification,  e.g.,  friend- 
to-hostile  or  h os t i  le - t o- f ri end  (this  action  also  generates 
an  ID  Change  alert). 

An  ID  conflict  is  said  to  exist  when  two  NTDS  Partici¬ 
pating  Units  (PU)  disagree  on  a  track's  identification.  ID 
conflicts  are  resolved  automatically  by  the  computer  (in 
favor  of  the  source  reporting  the  most  positive  information, 
e.g.,  confirmed  in  favor  of  assumed),  manually  by  the  par¬ 
ticipating  units,  or  unconditionally  by  the  force  ID  operator. 

Detailed  Task  Description 

1.  Bnter  Mode  and  Radar 

a.  Set  Mode  and  Radar  selector 

b.  Depress  Enter  Mode  and  Radar  QAB 
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Place  targets  in  Close  Control 
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a.  Depress  Sequence  QAB 

b.  Hook  symbol  appears  around  highest  priority 
target  not  presently  in  close  control  by 
another  ID  operator  (target  priority  is  com¬ 
puted  automatically  by  the  system,  on  a  con¬ 
fidence  level  basis). 

ID  Scenario 


1.  ID  operator  is  sequenced  to  an  unidentified  track. 

An  Unident  alert  is  displayed  on  his  alert  panel. 

2.  The  ’’expected"  action  is  for  the  ID  operator  to  make 
an  Identity  or  Class  entry.  He  may  clear  the  alert 
by  pressing  Sequence  (ID  not  attempted)  which  will 
sequence  him  to  another  target,  but  since  an  un¬ 
identified  track  has  a  high  sequencing  priority,  it 
will  soon  be  placed  in  close  control  again.  (ID 
doctrine  specifies  that  the  ID  operator  should  enter 
Unknown  rather  than  Sequence  in  this  situation,  and 
this  is  what  he  usually  does.) 

3.  The  ID  operator  attempts  to  identify  tracks  using 
1 17  F  /  S I F  .  He  will  do  this  by  entering  the  Request 
Interrogation  function  code  and  then  depressing  the 
Function  Code  button.  This  causes  the  Beacon  Video 
Processor  to  interrogate  a  position  in  space  cen¬ 
tered  on  the  position  of  the  hook  symbol,  i.e.,  to 
interrogate  the  track  in  close  control. 

a.  If  the  target  is  a  friendly  aircraft  and  if 
its  IFF  equipment  is  operating,  a  readout  of 
the  target’s  S1F  codes  (Modes  1,  2,  and  3) 
will  be  presented  on  the  UPA-50  display  panel. 
This  should  be  sufficient  to  positively  identify 
a  friendly  aircraft  provided  its  IFF  equipment 
is  operating  properly.  The  SIF  code  displayed 
on  the  UPA-50  is  entered  on  the  number  entry 
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the  track  and  can  be  called  up  on  the  DRO 
whenever  the  track  is  placed  in  close  control. 

b.  If  an  acceptable  IFF  response  is  not  received, 
the  ID  operator  will  attempt  to  contact  the 
aircraft  by  voice  radio  using  an  assumed  or 
indefinite  call  sign. 

If  communications  are  established  with  a 
friendly  aircraft  and  if  its  IFF  is  operable 
but  was  not  turned  on,  the  pilot  will  probably 
turn  it  on.  (Under  some  circumstances,  tac¬ 
tical  constraints  may  prohibit  the  pilot  from 
turning  on  his  IFF  gear.) 

If  communications  are  established  with  a  pilot 
who  claims  to  be  friendly  but  states  that  his 
IFF  is  inoperative,  he  is  told  to  respond  to 
ordered  maneuvers.  In  an  actual  hostile  en¬ 
vironment,  the  first  order  would  be  a  heading 
change  away  from  own-ship  (or  task  group). 

Ordered  maneuvers  are  prearranged  turn  patterns. 
For  example,  Ordered  Maneuver  Charlie  might  be 
a  series  of  three  90°  port  turns  followed  by  a 
180°  starboard  turn.  (It  is  not  always  ad¬ 
visable  to  use  the  ordered  maneuver  procedure. 

For  example,  a  friendly  strike  aircraft  return¬ 
ing  from  a  mission  may  be  low  on  fuel  or  damaged. 
In  such  a  case,  the  pilot  may  refuse  to  execute 
the  ordered  maneuver.) 

Friendly  aircraft  flying  missions  in  a  combat 
zone  fly  along  prearranged  flight  paths.  The 
ID  operator  draws  flight  paths  and  approach 
corridors  on  his  scope  (using  his  lines  General 
Purpose  Function  Code  [GPFC])  and  checks  to  see 
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is*  generally  con¬ 
forming  to  the  prearranged  plan.  Checkpoints 
can  also  be  indicated  (using  Points  GPFC) . 


c.  If  communications  cannot  be  established  with 
the  unidentified  aircraft,  command  may  decide 
to  lock-on  it  with  a  Fire  Control  radar  or  to 
check  it  out  visually  by  having  a  CAP  aircraft 
intercept  it. 

ID  Review 


The  ID  operator  reviews  the  ID  of  each  system  track  aperi- 
odically.  The  time  between  reviews  varies  primarily  as  a 
function  of  the  ID  confidence  level  assigned  to  the  track  ID, 
e.g.,  assumed  friend  tracks  are  reviewed  more  often  than  con¬ 
firmed  friend  tracks. 


The  procedures  used  during  the  ID  review  are  similar  to 
those  used  in  initial  ID. 


DETECTOR /TRACKER  (DET/TRK)  TASK  DESCRIPTION 
General 


The  primary  responsibilities  of  the  DET/TRK  are  to  detect 
targets,  enter  new  tracks  into  the  system  and  to  then  maintain 
an  accurate  track  on  each  track  in  his  assigned  sector  of 
responsibility. 

Detailed  Task  Description 

Initial  Equipment  Setup 

1.  Enter  Mode  and  Radar 

a.  Set  Mode  and  Radar  selector 

b.  Depress  Enter  Mode  and  Radar  push  button 

2.  Offset  PPI  display  (if  so  directed) 
a.  Roll  Ball  Tab  to  desired  offset 
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b.  Set  the  General  Purpose  Function  Code 
(GPFC)  for  automatic  offset 

c.  Press  Function  Code  button 

3.  Set  PPI  range  as  directed 

Radar  Search 

1.  Conduct  visual  search  of  assigned  sector 

2.  Detect  video.  Determine  if  a  track  number/symbol 
has  already  been  assigned  to  the  video. 

a.  Generally,  if  a  track  has  been  previously 
entered,  either  by  own-ship  or  another  NTDS 
unit,  a  track  symbol  will  be  associated  with 
the  piece  of  video. 

b.  It  is  possible,  however,  that  the  track  may 
have  been  previously  entered  by  another 
Participating  Unit  (PU)  but  due  to  a  grid¬ 
lock  error,  the  video  and  the  track  symbol 
are  apparently  not  associated  with  one 
another.  (See  Track  Supervisor  task  de¬ 
scription  for  a  discussion  of  gridlock.) 

Enter  Tentative  Track 

1.  Depress  Enable  Ball  Tab  Quick  Action  Button  (QAB) . 

2.  Use  Track  Ball  to  roll  the  Ball  Tab  symbol  to 
video. 

3.  Align  Ball  Tab  symbol  with  the  center  leading 
edge  of  video  (by  rolling  Track  Ball). 

4.  Depress  New  Track  push  button,  tentative  track 
symbol  appears  on  the  PPI  display  of  all  Input 
consoles . 

5.  After  three  updates,  the  New  Track  becomes  a 
firm  track  and  a  firm  track  symbol  appears  on 
Input  and  User  consoles  and  is  transmitted 
via  Link  11. 

6.  If  72  seconds  elapse  between  updates  of  a 
tentative  track,  the  track  is  automatically 
dropped  by  the  system. 
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Updating  Firm  Tracks 


1.  Each  firm  track  must  be  updated  every  72  seconds 
or  it  becomes  a  trouble  track.  Trouble  tracks 
are  indicated  by  blinking  track  symbols.  The 
blinking  feature  serves  as  a  reminder  to  all 
operators  that  the  track  has  not  been  updated 
recently.  It  does  not  necessarily  mean  that 
the  track  data  for  that  track  is  unreliable. 

2.  The  system  automatically  sequences  to  each 
track  m  turn.  Automatic  sequencing  takes 
place  in  response  to  either  a  Sequence  of 
Position  Correction  QA3  action. 

3.  The  system  dynamically  dead  reckons  track 
symbols  to  current  video  position,  i.e.,  the 
symbols  move  with  the  video  assuming  the  tar¬ 
get  does  not  maneuver  radically. 

4.  The  Hook  symbol  appears  around  the  track 
symbol  sequenced  to.  If  the  symbol  dot  ( /\  ) 
is  aligned  with  the  center  leading  edge  of 
the  video,  the  operator  updates  the  track* s 
position  by  pressing  his  Position  Correction 
QAB.  If  the  symbol  dot  is  not  properly  aligned 
with  the  video,  the  operator  enables  the 

Ball  Tab  by  pressing  the  Enable  Ball  Tab  QAB. 

He  then  uses  the  Track  Ball  to  roll  the  Ball 
Tab  and  align  it  with  the  center  leading 
edge  of  the  video.  Again,  the  new  position 
is  entered  by  depressing  the  Position  Cor¬ 
rection  button.  Pressing  the  Position  Cor¬ 
rection  QAB  causes  sequencing  to  occur. 

5.  The  Detect or/Tracker  retains  his  search 
responsibility  and  is  charged  with  search¬ 
ing  for  new  targets  no  matter  what  his 
tracking  load  may  be. 

Comment 

The  **averagel!  fleet  operator  reportedly  can  track  not 
more  than  6  to  10  targets  simultaneously.  Several  factors 
limit  the  number  of  tracks  a  tracker  can  track.  The  most 
apparent  limiting  factor  is  the  requirement  to  update  each 
track  every  72  seconds. 
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Reportedly,  the  most  severe  problem  encountered  by  the 
tracker  is  monotony.  Track  updating  is  an  easy,  highly 
repetitive  task.  There  was  substantial  agreement  among  the 
people  we  talked  to  that  most  trackers  become  ineffective 
and  should  be  rotated  about  every  30  minutes. 

The  major  cause  of  tracking  error  is  reported  to  be  the 
failure  of  the  tracker  to  accurately  align  the  ball  tab  to 
the  center  leading  edge  of  the  video.  This  problem  seems  to 
have  been  somewhat  alleviated  by  the  fleet  introduction  of 
the  AN/SPS-48  (series)  radar. 

Other  functions  performed  by  the  DET/TRKers  are  enter¬ 
ing  Late  Detections  and  track  Splits.  These  tasks  are,  how¬ 
ever,  in  reality  nothing  more  than  special  instances  in  the 
normal  tracking  situation. 

One  of  the  DET/TRK's  more  important  tasks  is  to  monitor 
his  own  past  performance.  Several  indications  permit  him  to 
do  this.  He  can  observe  and  compare  the  instantaneous  and 
continuous  positions  of  the  video  and  the  track  symbol.  They 
should  be  continuously  superimposed  on  one  another  assuming 
the  target  maintains  a  fairly  steady  course  and  speed.  By 
Function  Code  entry,  the  DET/TRK  can  call  up  a  track  history 
display.  The  track  history  consists  of  the  Ball  Tab  positions 
for  the  five  most  recent  updates.  The  Ball  Tab  positions 
should  form  either  a  straight  line  or  a  smooth  curve  and  should 
be  about  equidistant.  Yet  another  indication  the  DET/TRK  can 
use  to  check  on  his  past  performance  is  Track  Quality  (TQ) . 
Track  Quality  is  displayed  on  the  DRO  as  a  number  from  1-7, 
the  higher  the  number,  the  better  the  track  quality.  The  sys¬ 
tem  computes  track  quality  using  several  parameters  such  as 
time  elapsed  since  last  update,  track  smoothness,  etc. 

Through  a  judicious  interpretation  of  these  indications, 
the  DET/TRK  can  keep  himself  apprised  of  his  own  performance. 

If  he  is  not  performing  adequately,  the  TRK  SUP  will 
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(should)  take  whatever  action  is  necessary  to  ensure  that  his 
performance  improves. 
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SYMBOL 

MEANING 

© 

Surface  Friendly  Track 

Air  Friendly  Track 

o 

Subsurface  Friendly  Track 

□ 

Surface  Unknown  Track 

m 

Air  Unknown  Track 

LU 

Subsurface  Unknown  Track 

0 

Surface  Hostile  Track 

A 

Air  Hostile  Track 

V 

Subsurface  Hostile  Track 

@ 

Ownship 

0 

Aircraft  Carrier  Friendly 

•  ^ 

Surface  Hostile  Engaged 

V 

Subsurface  Hostile  Engaged 

*©' 

Surface  Friendly  Engaged 

M 

CAP  Station 

— . 

Corridor 
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SYMBOL 

MEANING 

4~ 

Formation  Center  (Utilization  Console  only) 

X 

Reference  Point 

K 

Data  Link  Reference  Point  (Reference  Point  and 
Unknown  Surface  symbols) 

X 

ECM  Fix 

<©> 

Tentative  Track  (Input  Consoles  only) 

GO 

Non-NTDS -Reported  Air  Track 

© 

Ball  Tab  (1/8"  dia.) 

( 

3 

Hook  (1/2"  dia.) 

• 

Pointer  (1/2"  dia.) 

f) 

Missile  Ship  Circle  and  Missile  Director  Lines 
(Utilization  Console  only) 

H 

Marshal  Point  (Corridor  Tab  and  CAP  Station' 
symbols) 

Clutter  Point  (Reference  Point  &  Tentative 

Track  Symbols)  (Input  Consoles  only) 

A 

Air  Hostile,  Raid  size  3  Unknown  or  One 

A 

Air  Hostile ,  Raid  size  3  Few 
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SYMBOL 

MEANING 

A 

Air  Hostile,  Raid  size  =  Many 

A 

Air  Hostile,  Assigned  to  Interceptor 

A 

Air  Hostile,  Engaged  by  Interceptor 

& 

Air  Hostile,  Assigned  to  Missiles 

4> 

Air  Hostile,  Assigned  to  Missiles  and/Director 

Assigned  (FCS  number  flashing  and  raoving  froa 

Air  Ready  position  near  ownship  to  target 
coordina tes ) 

& 

Air  Hostile,  Assigned  to  Missiles  and  Director 
Locked  On  (FCS  number  steady) 

£ 

Air  Hostile,  Assigned  to  Missiles,  Director 
Locked  On,  and  FCS  Ready 

$ 

Air  Hostile,  Assigned  to  Missiles,  Director 
Locked  On,  FCS  Ready,  and  Launcher  Assigned 

i' 

Air  Hostile,  Assigned  to  Missiles,  FCS  Ready, 
Launcher  Assigned,  and  Salvo  in  Flight 

Air  Hostile,  Assigned  tc  Missiles,  FCS  Ready, 
launcher  Assigned,  Salvo  in  Flight,  and  Third 
Salvo  Lockout 

a\ 

Interceptor 

ax 

Assigned  Interceptor 

jOx 

Engaged  Interceptor 

0 

Downed  Air  Friendly 
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SYMBOL 

M LAMING 

Air  Hostile  wi  th  Velocity  Leader 

Indicating  Northeasterly  Movement 

85 

PIM  (Position  and  Intended  Movement) 

(Reference  Point  and  Surface  Friend  symbols) 

o 

Vital  Area  (Variable  Diameter  Octagon) 

(Diameter  measured  across  line  termination 
points) 

0 

Bearing  Line  Point  (located  on  bearing  line 
approximately  30  miles  from  originating  ship) 

w 

ASROC  Water  Entry  Point 

c-s 
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Alexandria,  Virginia  22302 

Dr.  Daniel  B.  Jones 
Chief,  Military  Operations 
Martin  Marietta  Corporation 
P.  0.  Box  5857 
Orlando,  Florida  32805 

Ronald  A.  Erickson 

Head,  Human  Factors  Branch 

Code  3572 

Naval  Weapons  Center 

China  Lake,  California  93555 

Human  Factors  Division  Headquarters 
Air  Force  Systems  Command 
Andrews  Air  Force  Base 
Washington,  D.  C.  20331 
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Dr.  L.  Harrison 
Control  Image  Corporation 
2162  South  Jason  Street 
Denver,  Colorado  80223 

Applied  Research  Laboratories 
Attention:  Dr.  Charles  L.  Wood 

University  of  Texas 
Austin,  Texas  78712 

Chief,  Bureau  of  Medicine  8  Surgery 
Research  Division 
Department  of  the  Navy 
Washington,  D.  C.  20360 

Attention:  LCDR  Paul  Nelson,  MSC 

Dr.  Heber  G.  Moore 

Headquarters,  Navai  Material  Command 
Code  03RD 

Department  of  the  Navy 
Washington,  D.  C.  20360 

Dr.  A.  L.  Slafkoskv 
Scientific  Advisor 

Commandant  of  the  Marine  Corps  (Code  AX) 
Wash ing t on , • D .  C.  20380 

Commander,  U.  S.  Naval  Missile  Center 
Human  Factors  Fngineering  Branch 
Code  5342 

Point  Mugu,  California  93041 
Information  Display  Group 

U.  S.  Navy  Research  8  Development  Center 
Annapolis  Division 
Annapolis,  Maryland  21402 

Human  Factors  Department,  Code  55 
Attention:  Dr.  J.  J.  Regan 

Naval  Training  Device  Center 
Orlando,  Florida  32813 

U  S  N  Underwater  Systems  Center 
Attention:  Mr.  M.  Hunt 

New  London  Laboratory 
New  London,  Connecticut  06320 

Mr.  R.  Howard 
NAVSHIPS  Code  00V13 
Department  of  the  Navy 
Washington,  D.  C.  20360 
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Commander  Cruiser  Destroyer  Force 
U.  S.  Pacific  Fleet 
San  Diego,  California  92136 

Attention:  LTJG  Gus  Gutridge 

Code  425b 

Commander,  Operational  Test  5  Evaluation  Force 
U .  S .  Naval  Base 
Norfolk,  Virginia  23511 

Commander,  Operational  Test  $  Evaluation  Force 
U.  S.  Naval  Air  Station 
North  Island 

San  Diego,  California  92135 
Commanding  Officer 

Fleet  Computer  Programming  Center,  Pacific 
San  Diego,  California  92152 

Attention:  LCDR  A.  Johns 

Program  Evaluation 

Chief  of  Naval  Operations 
The  Pentagon 

Washington,  D.  C.  20350 

Attention:  CDR  R.  D.  Rodgers,  NOP-353 

Room  4D483 

Chief  of  Naval  Operations 
The  Pentagon 

Washington,  D.  C.  20350 

Attention:  LCDR  G.  F.  Hamilton,  NOP  982G12 

Room  5C739 

Commander,  First  Fleet 
Operational  Evaluation  Group 
U .  S .  Naval  Air  Station 
North  Island 

San  Diego,  California  92135 
Attention:  Dr.  M.  Millich 

Commander,  Second  Fleet 
Operational  Evaluation  Group 
U.  S.  Naval  Base 
Norfolk,  Virginia  23511 

Attention:  Mr.  W.  Putnam 
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Tracor,  Incorporated 
6500  Tracor  Lane 

Austin,  Texas  78721  1 

Air  Force  Office  of  Scientific  Research 
Attention:  Dr.  Harold  A.  Wooster 

Director  of  Information  Sciences 

Arlington,  Virginia  22209  1 

Naval  Ordnance  Laboratory 
White  Oak 

Attention:  Mr.  Robert  Flume 

Mr.  Harold  Lacey 

Silver  Spring,  Maryland  20910  2 

Dr.  Donald  T.  Hanifan 
Dunlap  and  Associates,  Inc. 

1454  Cloverfield  Boulevard 

Santa  Monica,  California  90404  1 

Human  Factors  Unit 
General  Electric  Company 
LIMED 

Farrell  Road,  Building  1 

Syracuse,  New  York  13201  1 

Mr.  Janies  Lang 
Human  Factors  Unit 
Sanders  Associates,  Inc. 

Nashua,  New  Hampshire  03060  ]_ 

Commanding  Officer 
Naval  Ship  Engineering  Center 
Prince  George's  Center 
Hyattsville,  Maryland  20782 

Attention:  Mr.  W.  O'Sullivan,  Code  6172  1 

Commanding  Officer 
Naval  Ship  Engineering  Center 
Prince  George's  Center 
Hyattsville,  Maryland  20782 

Attention:  Mr.  K.  Cress,  Code  6179  1 

Commanding  Officer 

Fleet  Computer  Programming  Center,  Atlantic 
Virginia  Beach,  Virginia  25461 

Mr.  E.  Brown,  Code  23A 
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Naval  Ship  Systems  Command 

National  Center  # 3 

2531  Jefferson  Davis  Highway 

Arlington,  Virginia  20360 


Attention:  CAPT  E.  C.  Svendsen 

Code  03 


Commanding  Officer 

FAAWTC  (Fleet  Anti-Air  Warfare  Training  Center) 
Catalina  Boulevard,  Point  Loma 
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Commanding  Officer 

FAAW'TC  (Fleet  Anti-Air  Warfare  Training  Center) 
Dam  Neck 

Virginia  Beach,  Virginia  23461 
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